分布式系统理论之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个副本，更新操做w_i 在W个副本中更新成功以后，才认为这次更新操做w_i 成功。称成功提交的更新操做对应的数据为：“成功提交的数据”。对于读操做而言，至少须要读R个副本才能读到这次更新的数据。其中，W+R>N ，即W和R有重叠。通常，W+R=N+1

假设系统中有5个副本，W=3，R=3。初始时数据为(V₁，V₁，V₁，V₁，V₁）--成功提交的版本号为1

当某次更新操做在3个副本上成功后，就认为这次更新操做成功。数据变成：(V₂，V₂，V₂，V₁，V₁）--成功提交后，版本号变成2

所以，最多只须要读3个副本，必定可以读到V₂(这次更新成功的数据)。而在后台，可对剩余的V₁ 同步到V₂，而不须要让Client知道。

 

二，Quorum机制分析

①Quorum机制没法保证强一致性

所谓强一致性就是：任什么时候刻任何用户或节点均可以读到最近一次成功提交的副本数据。强一致性是程度最高的一致性要求，也是实践中最难以实现的一致性。

 由于，仅仅经过Quorum机制没法肯定最新已经成功提交的版本号。

好比，上面的V₂ 成功提交后（已经写入W=3份），尽管读取3个副本时必定能读到V₂，若是恰好读到的是(V₂，V₂，V₂），则这次读取的数据是最新成功提交的数据，由于W=3，而此时恰好读到了3份V₂。若是读到的是（V₂，V₁，V₁），则没法肯定是一个成功提交的版本，还须要继续再读，直到读到V₂的达到3份为止，这时才能肯定V₂ 就是已经成功提交的最新的数据。

1）如何读取最新的数据？---在已经知道最近成功提交的数据版本号的前提下，最多读R个副本就能够读到最新的数据了。

2）如何肯定 最高版本号 的数据是一个成功提交的数据？---继续读其余的副本，直到读到的 最高版本号副本 出现了W次。

 

②基于Quorum机制选择 primary

中心节点(服务器)读取R个副本，选择R个副本中版本号最高的副本做为新的primary。

新选出的primary不能当即提供服务，还须要与至少与W个副本完成同步后，才能提供服务---为了保证Quorum机制的规则：W+R>N

至于如何处理同步过程当中冲突的数据，则须要视状况而定。

 好比，(V₂，V₂，V₁，V₁，V₁），R=3，若是读取的3个副本是：(V₁，V₁，V₁)则高版本的 V₂须要丢弃。

若是读取的3个副本是（V₂，V₁，V₁），则低版本的V₁须要同步到V₂

 

三，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