分布式系统设计(4)

先说一下前面三节介绍的内容，若是须要请参考，

第一节介绍数据分布方式：http://www.cnblogs.com/jacksu-tencent/p/3405680.html

第二节介绍副本控制协议：http://www.cnblogs.com/jacksu-tencent/p/3407712.html

第三节介绍基于Lease的分布式cache系统：http://www.cnblogs.com/jacksu-tencent/p/3409646.html

经过第三节的介绍，你们应该对Lease机制有必定的了解了，本节主要介绍Lease的本质，以及经过lease机制，如何来判断节点的状态，最后介绍在hdfs、chuby和zookeeper中如何应用lease机制。

Lease机制本质

Lease 是由颁发者授予的在某一有效期内的承诺。主要有两方面的承诺

一方面颁发者一旦发出 lease，则不管接受方是否收到，也不管后续接收方处于何种状态，只要 lease 不过时，颁发者必定严守承诺；

另外一方面，接收方在 lease 的有效期内可使用颁发者的承诺，但一旦 lease 过时，接收方必定不能继续使用颁发者的承诺。

就是只要lease不过时，颁发者必定严守承诺；一旦lease过时，接收方必定不能继续使用颁发者的承诺。

Lease机制容错能力

首先，经过引入有效期，Lease 机制有很是好的容错网络异常。 Lease 颁发过程只依赖于网络能够单向通讯，即便接收方没法向颁发者发送消息，也不影响 lease的颁发。因为 lease 的有效期是一个肯定的时间点，lease 的语义与发送 lease 的具体时间无关，因此同一个 lease 能够被颁发者不断重复向接受方发送。即便颁发者偶尔发送 lease 失败，颁发者也能够简单的经过重发的办法解决。一旦 lease 被接收方成功接受，后续 lease 机制再也不依赖于网络通讯，即便网络彻底中断 lease 机制也不受影响。

再者，Lease 机制能较好的容错节点宕机。若是颁发者宕机，则宕机的颁发者一般没法改变以前的承诺，不会影响 lease 的正确性。在颁发者机恢复后，若是颁发者恢复出了以前的 lease 信息，颁发者能够继续遵照 lease 的承诺。若是颁发者没法恢复 lease信息，则只需等待一个最大的 lease 超时时间就可使得全部的 lease 都失效，从而不破坏 lease 机制。例如上节中的 cache 系统的例子中，一旦服务器宕机，确定不会修改元数据，从新恢复后，只需等待一个最大的 lease 超时时间，全部节点上的缓存信息都将被清空。对于接受方宕机的状况，颁发者不须要作更多的容错处理，只需等待 lease 过时失效，就能够收回承诺，实践中也就是收回以前赋予的权限、身份等。

最后，lease 机制不依赖于存储。颁发者能够持久化颁发过的 lease 信息，从而在宕机恢复后可使得在有效期的 lease 继续有效。但这对于 lease 机制只是一个优化，如以前的分析，即便颁发者没有持久化 lease 信息，也能够经过等待一个最大的 lease 时间的方式使得以前全部颁发的 lease 失效，从而保证机制继续有效。

颁发方和接收方时间不一样步该如何处理呢？？？

分为两种状况：

若是颁发者的时钟比接收者的时钟慢，则当接收者认为 lease 已通过期的时候，颁发者依旧认为 lease 有效。接收者能够用在 lease 到期前申请新的 lease 的方式解决这个问题。

若是颁发者的时钟比接收者的时钟快，则当颁发者认为 lease 已通过期的时候，接收者依旧认为 lease 有效，颁发者可能将 lease颁发给其余节点，形成承诺失效，影响系统的正确性。对于这种时钟不一样步，实践中的一般作法是将颁发者的有效期设置得比接收者的略大，只需大过期钟偏差就能够避免对 lease 的有效性的影响。

基于lease机制如何肯定节点状态

经过一个例子来讨论这个问题：

在一个 primary-secondary 架构的系统中，有三个节点 A、B、C 互为副本，其中有一个节点为 primary，且同一时刻只能有一个 primary 节点。另有一个节点 Q 负责判断节点 A、B、C的状态，一旦 Q 发现 primary 异常，节点 Q 将选择另外一个节点做为 primary。假设最开始时节点 A为 primary，B、C 为 secondary。节点 Q 须要判断节点 A、B、C 的状态是否正常。

经过心跳没法很好判断节点状态

节点 A、B、C 能够周期性的向 Q 发送心跳信息，若是节点 Q 超过一段时间收不到某个节点的心跳则认为这个节点异常。这种方法的问题是假如节点 Q 收不到节点 A 的心跳，除了节点 A 自己的异常外，也有多是由于节点 Q 与节点 A 之间的网络中断致使的。在工程实践中，更大的可能性不是网络中断，而是节点 Q 与节点 A 之间的网络拥塞形成的所谓“瞬断”，“瞬断”每每很快能够恢复。另外一种缘由甚至是节点 Q 的机器异常，以致于处理节点 A 的心跳被延迟了，以致于节点 Q 认为节点 A 没有发送心跳。假设节点 A 自己工做正常，但 Q 与节点 A 之间的网络暂时中断，节点 A 与节点 B、C 之间的网络正常。此时节点 Q 认为节点 A 异常，从新选择节点 B 做为新的 primary，并通知节点 A、B、C 新的 primary 是节点 B。因为节点 Q 的通知消息到达节点 A、B、C 的顺序没法肯定，假如先到达 B，则在这一时刻，系统中同时存在两个工做中的 primary，一个是 A、另外一个是 B。假如此时 A、B 都接收外部请求并与 C 同步数据，会产生严重的数据错误。上述即所谓“双主”问题。

双主问题的解决

由中心节点向其余节点发送 lease，若某个节点持有有效的 lease，则认为该节点正常能够提供服务。如节点 A、 B、 C 依然周期性的发送 heart beat 报告自身状态，节点 Q 收到 heart beat后发送一个 lease，表示节点 Q 确认了节点 A、B、C 的状态，并容许节点在 lease 有效期内正常工做。节点 Q 能够给 primary 节点一个特殊的 lease，表示节点能够做为 primary 工做。一旦节点 Q 但愿切换新的 primary，则只需等前一个 primary 的 lease 过时，则就能够安全的颁发新的 lease 给新的primary 节点，而不会出现“双主”问题。

一个中心节点风险解决

借助chubby 和 zookeeper

lease 的有效期时间选择

常选择的 lease 时长是 10 秒级别，这是一个通过验证的经验值，实践中能够做为参考并综合选择合适的时长。

GFS 中的 Lease

GFS 中使用 Lease 肯定 Chuck 的 Primary 副本。 Lease 由 Master 节点颁发给 primary 副本，持有Lease 的副本成为 primary 副本。Primary 副本控制该 chuck 的数据更新流量，肯定并发更新操做在chuck 上的执行顺序。GFS 中的 Lease 信息由 Master 在响应各个节点的 HeartBeat 时附带传递（piggyback）。对于每个 chuck，其上的并发更新操做的顺序在各个副本上是一致的，首先 master选择 primary 的顺序，即颁发 Lease 的顺序，在每一任的 primary 任期内，每一个 primary 决定并发更新的顺序，从而更新操做的顺序最终全局一致。当 GFS 的 master 失去某个节点的 HeartBeat 时，只需待该节点上的 primary chuck 的 Lease 超时，就能够为这些 chuck 从新选择 primary 副本并颁发 lease。

Chubby 与 Zookeeper 中的 Lease

Chubby 中有两处使用到 Lease 机制。

咱们知道 chubby 经过 paxos 协议实现去中心化的选择 primary 节点。一旦某个节点得到了超过半数的节点承认，该节点成为 primary 节点，其他节点成为 secondary 节点。Secondary节点向 primary 节点发送 lease，该 lease 的含义是：“承诺在 lease 时间内，不选举其余节点成为 primary节点”。只要 primary 节点持有超过半数节点的 lease，那么剩余的节点就不能选举出新的 primary。一旦 primary 宕机，剩余的 secondary 节点因为不能向 primary 节点发送 lease，将发起新的一轮 paxos选举，选举出新的 primary 节点。

除了 secondary 与 primary 之间的 lease，在 chubby 中，primary 节点也会向每一个 client 节点颁发

lease。该 lease 的含义是用来判断 client 的死活状态，一个 client 节点只有只有合法的 lease，才能与chubby 中的 primary 进行读写操做。一个 client 若是占有 chubby 中的一个节点锁后 lease 超时，那么这个 client 占有的 chubby 锁会被自动释放，从而实现了利用 chubby 对节点状态进行监控的功能。另外， chubby 中 client 中保存有数据的 cache，故此 chubby 的 primary 为 cache 的数据颁发 cache lease，该过程与 前一节介绍的基于 lease 的 cahce 机制彻底相似。虽然相关文献上没有直接说明，但笔者认为，chubby 的 cache  lease 与 primary 用于判断 client 死活状态的 lease 是能够合并为同一个 lease的，从而能够简化系统的逻辑。

与 Chubby 不一样， Zookeeper 中的 secondary 节点（在 zookeeper 中称之为 follower）并不向 primary节点（在 zookeeper 中称之为 leader）发送 lease， zookeeper 中的 secondary 节点若是发现没有 primary节点则发起新的 paxos 选举，只要 primary 与 secondary 工做正常，新发起的选举因为缺少多数secondary 的参与而不会成功。与 Chubby 相似的是， Zookeeper 的 primary 节点也会向 client 颁发 lease，lease 的时间正是 zookeeper 中的 session 时间。在 Zookeeper 中，临时节点是与 session 的生命期绑定的， 当一个 client 的 session 超时，那么这个 client 建立的临时节点会被 zookeeper 自动删除。经过监控临时节点的状态，也能够很容易的实现对节点状态的监控。在这一点上，zookeeper 和 chubby 彻底是殊途同归。

下一节简单有效的副本管理机制quorum