分布式系统理论之Quorum机制
分布式系统理论之Quorum机制
一，Quorum机制介绍
在分布式系统中有个CAP理论，对于P（分区容忍性）而言，是实际存在 从而无法避免的。因为，分布系统中的处理不是在本机，而是网络中的许多机器相互通信，故网络分区、网络通信故障问题无法避免。因此，只能尽量地在C 和 A 之间寻求平衡。对于数据存储而言，为了提高可用性（Availability），采用了副本备份，比如对于HDFS，默认每块数据存三份。某数据块所在的机器宕机了，就去该数据块副本所在的机器上读取（从这可以看出，数据分布方式是按“数据块”为单位分布的）
但是，问题来了，当需要修改数据时，就需要更新所有的副本数据，这样才能保证数据的一致性（Consistency）。因此，就需要在 C(Consistency) 和 A(Availability) 之间权衡。
而Quorum机制，就是这样的一种权衡机制，一种将“读写转化”的模型。在介绍Quorum之前，先看一个极端的情况：WARO机制
WARO(Write All Read one)是一种简单的副本控制协议，当Client请求向某副本写数据时(更新数据)，只有当所有的副本都更新成功之后，这次写操作才算成功，否则视为失败。
从这里可以看出两点：①写操作很脆弱，因为只要有一个副本更新失败，此次写操作就视为失败了。②读操作很简单，因为，所有的副本更新成功，才视为更新成功，从而保证所有的副本一致。这样，只需要读任何一个副本上的数据即可。假设有N个副本，N-1个都宕机了，剩下的那个副本仍能提供读服务；但是只要有一个副本宕机了，写服务就不会成功。
WARO牺牲了更新服务的可用性，最大程度地增强了读服务的可用性。而Quorum就是更新服务和读服务之间进行一个折衷。
Quorum机制是“抽屉原理”的一个应用。定义如下：假设有N个副本，更新操作wi 在W个副本中更新成功之后，才认为此次更新操作wi 成功。称成功提交的更新操作对应的数据为：“成功提交的数据”。对于读操作而言，至少需要读R个副本才能读到此次更新的数据。其中，W+R>N ，即W和R有重叠。一般，W+R=N+1
假设系统中有5个副本，W=3，R=3。初始时数据为(V1，V1，V1，V1，V1）--成功提交的版本号为1
当某次更新操作在3个副本上成功后，就认为此次更新操作成功。数据变成：(V2，V2，V2，V1，V1）--成功提交后，版本号变成2
因此，最多只需要读3个副本，一定能够读到V2(此次更新成功的数据)。而在后台，可对剩余的V1 同步到V2，而不需要让Client知道。
二，Quorum机制分析
①Quorum机制无法保证强一致性
所谓强一致性就是：任何时刻任何用户或节点都可以读到最近一次成功提交的副本数据。强一致性是程度最高的一致性要求，也是实践中最难以实现的一致性。
因为，仅仅通过Quorum机制无法确定最新已经成功提交的版本号。
比如，上面的V2 成功提交后（已经写入W=3份），尽管读取3个副本时一定能读到V2，如果刚好读到的是(V2，V2，V2），则此次读取的数据是最新成功提交的数据，因为W=3，而此时刚好读到了3份V2。如果读到的是（V2，V1，V1），则无法确定是一个成功提交的版本，还需要继续再读，直到读到V2的达到3份为止，这时才能确定V2 就是已经成功提交的最新的数据。
1）如何读取最新的数据？---在已经知道最近成功提交的数据版本号的前提下，最多读R个副本就可以读到最新的数据了。
2）如何确定 最高版本号 的数据是一个成功提交的数据？---继续读其他的副本，直到读到的 最高版本号副本 出现了W次。
②基于Quorum机制选择 primary
中心节点(服务器)读取R个副本，选择R个副本中版本号最高的副本作为新的primary。
新选出的primary不能立即提供服务，还需要与至少与W个副本完成同步后，才能提供服务---为了保证Quorum机制的规则：W+R>N
至于如何处理同步过程中冲突的数据，则需要视情况而定。
比如，(V2，V2，V1，V1，V1），R=3，如果读取的3个副本是：(V1，V1，V1)则高版本的 V2需要丢弃。
如果读取的3个副本是（V2，V1，V1），则低版本的V1需要同步到V2
三，Quorum机制应用实例
HDFS高可用性实现
HDFS的运行依赖于NameNode，如果NameNode挂了，那么整个HDFS就用不了了，因此就存在单点故障(single point of failure)；其次，如果需要升级或者维护停止NameNode，整个HDFS也用不了。为了解决这个问题，采用了QJM机制(Quorum Journal Manager)实现HDFS的HA（High Availability）。注意，一开始采用的“共享存储”机制，关于共享存储机制的不足，可参考：（还提到了QJM的优点）
In a typical HA cluster, two separate machines are configured as NameNodes. At any point in time, exactly one of the NameNodes is in an Active state, and the other is in a Standby state. The Active NameNode is responsible for all client operations in the cluster, while the Standby is simply acting as a slave, maintaining enough state to provide a fast failover if necessary.
为了实现HA，需要两台NameNode机器，一台是Active NameNode，负责Client请求。另一台是StandBy NameNode，负责与Active NameNode同步数据，从而快速 failover。
那么，这里就有个问题，StandBy NameNode是如何同步Active NameNode上的数据的呢？主要同步是哪些数据呢？
数据同步就用到了Quorum机制。同步的数据 主要是EditLog。
In order for the Standby node to keep its state synchronized with the Active node, both nodes communicate with a group of separate daemons called “JournalNodes” (JNs).
数据同步用到了一个第三方”集群“：Journal Nodes。Active NameNode 和 StandBy NameNode 都与JournalNodes通信，从而实现同步。
''''''''''''''''''''''''''''''''''
每次 NameNode 写 EditLog 的时候，除了向本地磁盘写入 EditLog 之外，也会并行地向 JournalNode 集群之中的每一个 JournalNode 发送写请求，只要大多数 (majority) 的 JournalNode 节点返回成功就认为向 JournalNode 集群写入 EditLog 成功。如果有 2N+1 台 JournalNode，那么根据大多数的原则，最多可以容忍有 N 台 JournalNode 节点挂掉。
这就是：Quorum机制。每次写入JournalNode的机器数目达到大多数(W)时，就认为本次写操作成功了。
'''''''''''''''''''''''''''''''''
这样，每次对Active NameNode中的元数据进行修改时，都会将该修改写入JournalNode集群的大多数机器中，才认为此次修改成功。
当Active NameNode宕机时，StandBy NameNode 向JournalNode同步EditLog，从而保证了HA。
Active NameNode 向 JournalNode 集群提交 EditLog 是同步的 但 Standby NameNode 采用的是定时从 JournalNode 集群上同步 EditLog 的方式，那么 Standby NameNode 内存中文件系统镜像有很大的可能是落后于 Active NameNode 的， 所以 Standby NameNode 在转换为 Active NameNode 的时候需要把落后的 EditLog 补上来。
具体的同步过程可参考： Hadoop NameNode 高可用 (High Availability) 实现解析
In order to provide a fast failover, it is also necessary that the Standby node have up-to-date information regarding the location of blocks in the cluster. In order to achieve this, the DataNodes are configured with the location of both NameNodes, and send block location information and heartbeats to both.
此外，为了实现快速failover，StandBy NameNode 需要实时地与各个DataNode通信以获得每个数据块的地址信息。为咐要这样？
因为：每个数据块的地址信息不属于“元信息”，并没有保存在 FsImage、CheckPoint...，这是因为地址信息变化比较大。比如说，一台DataNode下线了，其上面的数据块地址信息就全无效了，而且为了达到指定的数据块“复制因子”，还需要在其他机器上复制该数据块。
而快速failover，是指Active NameNode宕机后，StandBy NameNode立即就能提供服务。因此，DataNode也需要实时向 StandBy NameNode 发送 block report
另外，还有手动failover 和 自动 failover，自动failover需要Zookeeper的支持，具体可参考官网：HDFS High Availability Using the Quorum Journal Manager
如何避免“Split Brain”(脑裂)问题？
Split Brain 是指在同一时刻有两个认为自己处于 Active 状态的 NameNode。
when a NameNode sends any message (or remote procedure call) to a JournalNode, it includes its epoch number as part of the request. Whenever the JournalNode receives such a message, it compares the epoch number against a locally stored value called the promised epoch. If the request is coming from a newer epoch, then it records that new epoch as its promised epoch.If instead the request is coming from an older epoch, then it rejects the request. This simple policy avoids split-brain
简单地理解如下：每个NameNode 与 JournalNodes通信时，需要带一个 epoch numbers(epoch numbers 是唯一的且只增不减)。而每个JournalNode 都有一个本地的promised epoch。拥有值大的epoch numbers 的NameNode会使得JournalNode提升自己的 promised epoch，从而占大多数，而epoch numbers较小的那个NameNode就成了少数派(Paxos协议思想)。
从而epoch number值大的NameNode才是真正的Active NameNode，拥有写JournalNode的权限。注意：（任何时刻只允许一个NameNode拥有写JournalNode权限）
when using the Quorum Journal Manager, only one NameNode will ever be allowed to write to the JournalNodes, so there is no potential for corrupting the file system metadata from a split-brain scenario.
具体实现可参考：（还提到了QJM的优点）
四，参考资料
维基百科Quorum
https://issues.apache.org/jira/secure/attachment/12547598/qjournal-design.pdf
Hadoop2.6.0学习笔记（九）SPOF解决方案Quorum机制
HDFS HA与QJM[官网整理]
原文地址：http://www.cnblogs.com/hapjin/p/5626889.html
分布式系统理论之Quorum机制相关推荐
- 分布式系统理论：Quorum算法
前言 笔者在分布式一致性算法的重要原理:鸽巢原理中介绍了鸽巢原理,而本文将要介绍Quorum算法正是鸽巢原理的应用之一.本文将按以下顺序对Quorum算法进行介绍: 分布式系统为什么需要Quorum算 ...
- 分布式系统理论之租约机制学习
一,租约机制介绍 在分布式系统中,往往会有一个中心服务器节点.该节点负责存储.维护系统中的元数据.如果系统中的各种操作都依赖于中心服务器上的元数据,那么中心服务器很容易成为性能瓶颈及存在单点故障.而通 ...
- 五分钟学后端技术：分布式系统理论 - 从放弃到入门
转载声明 本系列文章转自某技术大佬的博客https://www.cnblogs.com/bangerlee/ 该系列文章是我在网上能够找到的最全面的分布式理论介绍文章了,一直没看到有人整理这个系列文章 ...
- 分布式系统原理 之4 Quorum 机制
分布式系统原理 Quorum 机制 Quorum 机制是一种简单有效的副本管理机制.本节首先讨论一种最简单的副本控制规则write-all-read-one,在此基础上,放松约束,讨论 quorum ...
- leetcode每日一题--雀巢原理；抽屉算法；Quorum机制；分布式应用
leetcode每日一题 539. 最小时间差 示例 1: 输入:timePoints = ["23:59","00:00"] 输出:1 示例 2: 输入:ti ...
- 分布式系统Quorum机制
Write-all-read-one Write-all-read-one(简称 WARO)是一种最简单的副本控制规则,顾名思义即在更新时写所有的副本,只有在所有的副本上更新成功,才认为更新成功,从而 ...
- 「分布式系统理论」系列专题
如今互联网已经成为整个社会的基础设施,分布式系统并不是少数大公司的专属,所以分布式系统理论可能是你迟早需要掌握的知识. 如果你是程序员,相信这些文章你肯定能看懂:如果你不是程序员,相信这些能使你能更懂 ...
- seata分布式事务回滚机制是如何实现的
本文来说下seata分布式事务回滚机制是如何实现的 文章目录 概述 概述
- seata分布式事务一致性锁机制如何实现的
本文来说下seata分布式事务一致性锁机制是如何实现的 文章目录 概述 概述
- Hadoop2.6.0学习笔记（九）SPOF解决方案Quorum机制
鲁春利的工作笔记,谁说程序员不能有文艺范? 以下内容转载自:Eric雪菲的Quorum机制漫谈和junhua3344的Quorum机制 Quorum这个词的念作"科瑞姆",字面意思 ...
最新文章
- HTML CSS JS之间的关系
- 【渝粤教育】广东开放大学 会议运行管理 形成性考核 (38)
- centos5.3搭建安全高效的LNMP服务器
- 前端学习（3219）：对props进行限制
- 我的家庭私有云计划-10
- TiDB集群大规模删除实践
- 记一次MongoDB故障排查的过程
- php视频文件设置期限,如何使用PHP检测视频文件持续时间(以分钟为单位)？
- C++中数字和字符串的转换
- Srping MVC中Controller的void方法声明误区
- jQuery拖动调整表格列宽度-resizableColumns
- 海康摄像头rtsp流格式
- Nutch是一个优秀的开源的数据爬取框架
- c语言的字符与字符串拼接,详解C语言中的字符串拼接(堆与栈)
- MySQL中幻读是如何解决的
- 互联网+是什么意思？
- pptpd mysql_pptpd+freeradius+mysql安装步骤
- 企业采用云计算的战略路线图
- php 邮件群发 http协议,邮件群发【超高的成功率/到达率、SMTP模式、支持HTTP协议】...
- log4j同配置下多个进程写日志