分布式学习之Quorum机制和Lease机制

Quorum 机制

感觉这个名字很难读，今晚百度了一下，其实是这样的，腐朽的西方资本主义社会在举行选举时，通常要求参与人数必须达到额定的数量，才能成为一个法定有效的选举。这个额定的人数就

是Quorum，这是原始的涵义，哈哈。

首先明确一下Quorum 机制（管理副本机制）和lease机制（管理cache机制）是不同的范畴

• 相似：Cache 机制与多副本机制的相似之处都是将一份数据保存在多个节点上。 
•  不同：Cache 机制却要简单许多,对于 cache 的数据,可以随时删除丢弃,并命中 cache 的后果仅仅是需要访问数据源读取数据;然而副本机制却不一样,副本是不能 随意丢弃的,每失去一个副本,服务质量都在下降,一旦副本数下降到一定程度,则往往服务将不 再可用。 

 write-all-read-one(读可用性较高，更新可用性差)

 分布式系统通常支持多副本，副本存放在不同节点上，读写时需要对多个副本进行操作。按照自然而然的想法，一个写操作会需要写多个副本，但是读只要读到一个副本即可。这种思路猛听起来很合理，但若真依此实现，每一次写都必须刷新所有副本，才能避免产生一致性问题，如此写操作就显得太“重”了，尤其是和读操作相比较，一头轻一头重，负载明显不平衡，更加显得不协调。而且写的respond time变长其实也会间接影响到读，因为不写好没法读嘛，最终拖慢整体性能，是不是感觉被猛击了一下，哈哈。

Quorum 机制

Quorum的原理其实是我们家喻户晓的原理：鸽笼原理：若有n+1只鸽子关在n个笼子里，那么至少有一个笼子有至少2只鸽子，记得《算法经典入门》那本书里有介绍，经常搞这玩意。记得我做过的一道算法题：http://poj.org/problem?id=2356，有兴趣可以练练手，也可以拿去坑坑面试的人哈哈。鸽笼原理在Quorum的具体应用其实就是读副本数+写副本要大于总副本数。

 

Quorum 机制的三个系统参数 N、W、R 控制了系统的可用性,也是系统对用户的服务承诺:数 据最多有 N 个副本,但数据更新成功 W 个副本即返回用户成功。对于一致性要求较高的 Quorum 系 统,系统还应该承诺任何时候不读取未成功提交的数据,即读取到的数据都是曾经在 W 个副本上成 功的数据。 

例子：N＝5，W＝3，R＝3，只要更新成功 3个副本即返回用户成功，原来的版本都为data_V1，其中我们对其中的三个副本改称data_V2,读取的时候我在5个副本中选取任意3个副本，其中必要我修改后的版本data_V2。示意图：

 

现在的问题明显地出现：

1.如何读取最新成功提交的数据，即我怎么知道data_V2 是最新地版本（假设读地时候不知道已提交的数据版本号 ）

2.如何选择 primary 

对于第一个问题：

Quorum 机制只需成功更新 N 个副本中的 W 个,在读取 R 个副本时,一定可以读到包含最新的成功 提交的数据。但由于有不成功的更新情况存在,仅仅读取 R 个副本却不一定能确定哪个版本的数据是最新的已提交的数据。 

Lease 机制

 这种机制目的

在一个分布式系统中,有一个中心服务器节点存储、维护着一些数据。如果每次读取数据的操作都访问中心服务器节点,那么中心服务器节点的会承受不了的。为此,设计一种cache,在各个节点上 cache 数据信息来提高性能。要求各个节点上 cache 的数据始终与中心服务器上的数据一致,cache 数据不能是旧的脏数据。cache 系统要能最大可能的处理节点宕机、网络中断等异常。

机制的流程

有客户端节点，cache节点，数据中心节点，客户端对数据的读取和修改不会直接操作数据中心节点，而是通过cache节点。

1)客户端的读取cache节点流程：

判断元数据是否已经处于本地 cache 且 lease 处于有效期内 ：

• 是：直接返回数据
• 否：向中心服务器节点请求读取数据信息 ，服务器收到读取请求后,返回元数据及一个对应的 lease，如果cache节点收到失败或超时:退出流程,读取失败,可重试，成功:将元数据与该元数据的lease记录到内存中,返回元数据 

 2)客户端节点修改元数据流程

•  1节点向服务器发起修改数据请求。
•  2 服务器收到修改请求后,阻塞所有新的读数据请求,即接收读请求,但不返回数据。
•  3 服务器等待所有与该数据相关的 lease 超时。
•  4 服务器修改数据并向客户端节点返回修改成功。 

个人理解：

Lease 是由数据中心节点的的承诺，承诺他的节点数据在这段时间是有效的，比如redis的expire时间。数据中心节点一旦发 出 lease,则无论接受方是否收到,也无论后续接收方处于何种状态,

只要 lease 不过期,数据中心节点一 定严守承诺，保持与连接他的节点保持一致;另一方面,接收方在 lease 的有效期内可以使用数据中心节点的承诺,但一旦 lease 过期,接收方一定不能继续使

用数据中心节点的承诺。 

lease 机制确定节点状态 

不用lease的心跳机制是不能保持所有节点状态的一致性的

例子：M 负责判断节点 是S1、S2、S3 的状态，M与节点 A 之间的网络暂时中断之前，M选取S1为primary，S2和S3为

secondary，假设节点 S1 本身工作正常,但 M与节点 A 之间的网络暂时中断,M听不到S1的心跳，但节点 S1 与节点 S2、S3 之间的网络正常。此时节点 M 认为节点 S2 异常,重新选择节点

S2 作为新的 primary,并通知节点 S1、S2、S3 新 的 primary 是节点 S2。由于节点 Q 的通知消息到达节点 S1、S2、S3 的顺序无法确定,假如先到达 S2, 则在这一时刻,系统中同时存在两个

工作中的 primary,一个是 S1、另一个是S2。假如此时 S1、S2  接收外部请求并与 S3 同步数据,会产生严重的数据错误。

解决例子的方法：

节点 S1、S2、S3 依然周期性的发送 心跳报告自身状态,节点 M 收到心跳后发送一个 lease,表示节点 M 确认了节点 S1、S2、S3 的状态,并允许节点在 lease 有效期内正常工 作。节点 M 可

以给 primary 节点一个特殊的 lease,表示节点可以作为 primary 工作。一旦节点 M希 望切换新的 primary,则只需等前一个 primary 的 lease 过期,则就可以安全的颁发新的 lease 给新primary 节点 。

 

Zookeeper 中的lease机制：

 follower节点并不向leader发送 lease,zookeeper 中的 follower 节点如果发现没有 leader 节点则发起新的一轮选举,只要 leader 与 follower 工作正常,新发起的选举由于缺乏多数 follower 的参与而不会成功。Zookeeper 的 leader 节点也会向 follower 颁发 lease, lease 的时间是 zookeeper 中的 session 时间。在 Zookeeper 中,临时节点是与 session 的生命期绑定 的,当一个follower 的 session 超时,那么这个 follower 创建的临时节点会被 zookeeper 自动删除。通过监控临时节点的状态,也可以很容易的实现对节点状态的监控。