分布式系统基础--注册中心Zookeeper相遇2

 文章最前： 我是Octopus，这个名字来源于我的中文名--章鱼；我热爱编程、热爱算法、热爱开源。所有源码在我的个人github ；这博客是记录我学习的点点滴滴，如果您对 Python、Java、AI、算法有兴趣，可以关注我的动态，一起学习，共同进步。

相关文章：

1. 分布式系统基础--注册中心Zookeeper初识1
2. 分布式系统基础--注册中心Zookeeper相遇2
3. 分布式系统基础-- 注册中心Zookeeper应用3
4. 分布式系统基础-- 注册中心Zookeeper应用4（分布式锁）

---

1. 了解 zookeeper 及 zookeeper 的设计猜想    
2. zookeeper 集群角色
3. 深入分析 ZAB 协议

---

 一. 了解 zookeeper 及 zookeeper 的设计猜想    

     1.1 zookeeper  

     分布式系统的很多难题，都是由于缺少协调机制造成的。 在分布式协调这块做得比较好的，有 Google 的 Chubby 以及 Apache 的 Zookeeper。Google Chubby 是一个分布式锁服务，通过 Google Chubby 来解决分布式协作、 Master 选举等与分布式锁服务相关的问题。

         Zookeeper 也是类似，因为当时在雅虎内部的很多系统都需要依赖一个系统来进行分布式协调，但是谷歌的Chubby是不开源的，所以后来雅虎基于 Chubby 的思想开发了zookeeper，并捐赠给了 Apache。在上面这个架构下 zookeeper 以后，可以用来解决 task 执行问题，各个服务先去 zookeeper 上去注册节点，然后获得权限以后再来访问 task。

      1.2 zookeeper的设计猜想

      zookeeper 主要是解决分布式环境下的服务协调问题而产生的，如果我们要去实现一个 zookeeper 这样的中间件。
        防止单点故障
        如果要防止 zookeeper 这个中间件的单点故障，那就势必要做集群。而且这个集群如果要满足高性能要求的话，还得是一个高性能高可用的集群。高性能意味着这个集群能够分担客户端的请求流量，高可用意味着集群中的某一个节点宕机以后，不影响整个集群的数据和继续提供服务的可能性。
结论： 所以这个中间件需要考虑到集群,而且这个集群还需要分摊客户端的请求流量

        leader节点的选举

        如果要满足这样的一个高性能集群，我们最直观的想法应该是，每个节点都能接收到请求，并且每个节点的数据都必须要保持一致。要实现各个节点的数据一致性，就势必要一个 leader 节点负责协调和数据同步操作。这个我想大家都知道，如果在这样一个集群中没有 leader 节点，每个节点都可以接收所有请求，那么这个集群的数据同步的复杂度是非常大。
结论：所以这个集群中涉及到数据同步以及会存在leader 节点，zookeeper 用了基于 paxos 理论所衍生出来的 ZAB 协议，来进行leader的选举。

        保证数据一致性

        leader 节点如何和其他节点保证数据一致性，并且要求是强一致的。在分布式系统中，每一个机器节点虽然都能够明确知道自己进行的事务操作过程是成功和失败，但是却无法直接获取其他分布式节点的操作结果。所以当一个事务操作涉及到跨节点的时候，就需要用到分布式事务，分布式事务的数据一致性协议有 2PC 协议和3PC 协议。
        关于 2PC 提交、

        （Two Phase Commitment Protocol） 当一个事务操作需要跨越多个分布式节点的时候，为了保持事务处理的 ACID特性，就需要引入一个“协调者”（TM）来统一调度所有分布式节点的执行逻辑，这些被调度的分布式节点被称为 AP。TM 负责调度 AP 的行为，并最终决定这些 AP 是否要把事务真正进行提交；因为整个事务是分为两个阶段提交，所以叫 2PC。

                                          
阶段一：提交事务请求（投票）

      1. 事务询问
      协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应
       2. 执行事务
      各个参与者节点执行事务操作，并将 Undo 和 Redo 信息记录到事务日志中，尽量把提交过程中所有消耗时间的操作和准备都提前完成确保后面 100%成功提交事务
      3. 各个参与者向协调者反馈事务询问的响应
      如果各个参与者成功执行了事务操作，那么就反馈给参与者yes 的响应，表示事务可以执行；如果参与者没有成功执行事务，就反馈给协调者 no 的响应，表示事务不可以执行，上面这个阶段有点类似协调者组织各个参与者对一次事务操作的投票表态过程，因此 2pc 协议的第一个阶段称为“投票阶段”，即各参与者投票表名是否需要继续执行接下去的事务提交操作。
阶段二：执行事务提交
      在这个阶段，协调者会根据各参与者的反馈情况来决定最终是否可以进行事务提交操作，正常情况下包含两种可能:执行事务、中断事务。

二. zookeeper 集群角色

         在 zookeeper 中，客户端会随机连接到 zookeeper 集群中的一个节点，如果是读请求，就直接从当前节点中读取数据，如果是写请求，那么请求会被转发给 leader 提交事务，然后 leader 会广播事务，只要有超过半数节点写入成功，那么写请求就会被提交（类 2PC 事务）。

                                    
        所有事务请求必须由一个全局唯一的服务器来协调处理，这个服务器就是 Leader 服务器，其他的服务器就是follower； leader 服务器把客户端的失去请求转化成一个事务 Proposal（提议），并把这个 Proposal 分发给集群中的所有 Follower 服务器。之后 Leader 服务器需要等待所有Follower 服务器的反馈，一旦超过半数的 Follower 服务器进行了正确的反馈，那么Leader 就会再次向所有的Follower 服务器发送 Commit 消息，要求各个 follower 节点对前面的一个 Proposal 进行提交。

集群角色
Leader 角色
        Leader 服务器是整个 zookeeper 集群的核心，主要的工作任务有两项
       1. 事物请求的唯一调度和处理者，保证集群事物处理的顺序性
       2. 集群内部各服务器的调度者
Follower 角色
       Follower 角色的主要职责是
      1. 处理客户端非事物请求、转发事物请求给 leader 服务器
      2. 参与事物请求 Proposal 的投票（需要半数以上服务器通过才能通知 leader commit 数据; Leader 发起的提案，要求 Follower 投票）
      3. 参与 Leader 选举的投票

Observer 角色
         Observer 是 zookeeper3.3 开始引入的一个全新的服务器角色，从字面来理解，该角色充当了观察者的角色。观察 zookeeper 集群中的最新状态变化并将这些状态变化同步到 observer 服务器上。 Observer 的工作原理与follower 角色基本一致，而它和 follower 角色唯一的不同在于 observer 不参与任何形式的投票，包括事物请求Proposal的投票和 leader选举的投票。简单来说，observer服务器只提供非事物请求服务，通常在于不影响集群事物处理能力的前提下提升集群非事物处理的能力。

集群组成

        通常 zookeeper 是由 2n+1 台 server 组成，每个 server 都知道彼此的存在。 对于 2n+1 台 server，只要有 n+1 台（大
多数） server 可用，整个系统保持可用。 我们已经了解到，一个 zookeeper 集群如果要对外提供可用的服务，那么集群中必须要有过半的机器正常工作并且彼此之间能够正常通信，基于这个特性，如果向搭建一个能够允许 F 台机器down 掉的集群，那么就要部署 2*F+1 台服务器构成的zookeeper 集群。 因此 3 台机器构成的 zookeeper 集群，能够在挂掉一台机器后依然正常工作。一个 5 台机器集群的服务，能够对 2 台机器挂掉的情况下进行容灾。如果一台由 6 台服务构成的集群，同样只能挂掉 2 台机器。因此，5 台和 6 台在容灾能力上并没有明显优势，反而增加了网络通信负担。 系统启动时， 集群中的 server 会选举出一台server 为 Leader，其它的就作为 follower（这里先不考虑observer 角色）。之所以要满足这样一个等式，是因为一个节点要成为集群中的 leader，需要有超过及群众过半数的节点支持，这个涉及到 leader 选举算法。同时也涉及到事务请求的提交投票。

3. 深入分析 ZAB 协议

       ZAB（Zookeeper Atomic Broadcast）协议是为分布式协调服务Zookeeper专门设计的一种支持崩溃恢复的原子广播协议，在zookeeper中，主要依赖ZAB协议来实现数据一致性，基于该协议，zookeeper实现了主备模式的系统架构来保持集群中各副本之间的数据一致性问题。

ZAB协议介绍

ZAB协议包含两种基本模式，分别是：

1.崩溃恢复

2.原子广播

       当整个集群启动时或当leader节点出现网络中断，崩溃等情况时，ZAB协议就会进入恢复模式并选举产生新的Leader，当Leader服务器选举出来或，并且集群中有过半的机器和该leader节点完成数据同步后（同步指的是数据同步，用了保证集群中过半的机器能够和leader服务器的数据状态保持一致）ZAB协议就退出恢复模式。

       当集群中已经有过半的Follower节点完成了和leader状态同步后，那么整个集群就进入了消息广播模式。这个时候，在leader节点正常工作时，启动一台新的服务器加入到集群，那么集群将进入数据恢复模式，和leader节点进行数据同步。同步完成后即可正常对外提供非事物请求处理。

消息广播的实现原理
         如果了解分布式事物的2PC和3PC协议的话，消息广播的过程实际上是一个简化版的二阶级提交过程：

        1.leader接收到消息请求后，将消息赋予一个全局唯一的64位自增id,叫做zxid,通过zxid的大小比较可以实现因果有序这个特征。
        2.leader为每个follower准备了一个FIFO队列（通过tcp协议来实现，以实现全局有序这一特点）将带有zxid的消息作为提案（Proposal）分发给follower。

       3.当follower接收到proposal，先把proposal写到磁盘，写入成功后再想leader回复一个ACK;

       4.当leader接收到合法数量（超过半数）的ACK后，leader就会向这些follow发送commit命令，同时会在本地执行这些消息；

       5.当follower收到消息的commit命令后，会提交该消息。

                                  

        当leader的投票过程，不需要Observer的ACK,也就是Observer不需要参与投票过程，但是Observer必须要同步Leader的数量从而在处理请求保证数据的一致性。

崩溃恢复（数据恢复）

       ZAB协议的这个基于原子广播协议的消息广播过程，在正常情况下没有任何问题的，但是一旦Leader节点崩溃，由于网络问题导致Leader服务器失去了过半的Follower节点的连续（Leader失去与过半follower节点联系，可能是leader节点和follower节点之间产生了网络分区，那么leader就不再是合法的leader了）那么就进入到崩溃恢复模式。在ZAB协议中，为了保证程序的正确运行，整个恢复过程结束后需要选举出一个新的leader，为了使leader挂了后系统能正常工作，需要解决两个问题：

1.已经被处理的消息不能丢失

         当leader收到合法数量follower的ACKs后，就向各个follower广播commit命令，同时也会在本地执行commit并向连接的客户端返回成功，但是如果在各个follower在收到commit命令前leader就挂掉了，导致剩下的服务器并没有执行这条消息。

                             
          leader对事物消息发起commit操作，但是该消息在follower1上执行了，但是在follow2还没有收到commit，就已经挂掉了，实际上客户端已经收到该事务消息处理成功的回执了，所以zab协议下需要保证所有机器都要执行这个事务消息。

2.被丢弃的消息不能再出现

          当leader接收到消息请求生成proposal后就挂掉了，其他follower 并没有收到proposal，因此经过恢复模式重新选了leader后，这条消息是被跳过的，此时之前挂了的leader重新启动并注册成了follower，他保留了被跳过消息的proposal状态，与整个系统的状态不是一致的，将其删除。

        ZAB协议需要满足上面两种情况，就必须要设计一个leader选举算法：能够确保已经被leader提交的事务Proposal能够提交，同时丢弃已经跳过的事务proposal。

针对这个要求：

         如果leader选举算法能够保证新选举出来的Leader服务器拥有集群中所有机器最高编号（Zxid）的事务proposal，那么就可以保证这个新选举出来的leader一定具有已经提交的提案。因为所有提案被commit之前必须有超过半数的follower ACK，即必须有超过半数节点的服务器和事务日志上有该提案的proposal，因此，只要有合法数量的节点正常工作，就必然有一个节点保存所有被commit消息的proposal状态。另外一个，zxid是64位，高32位是epoch编号，每经过一次leader选举产生一个新的leader，新的leader会将epoch号+1，新leader选举后这个值重置为0，这样设计的好处在于老的leader挂了以后重启，它不会被选举为leader，因此此时它的zxid肯定小于当前新的leader。当老的leader作为follower接入新的leader之后，新的leader会让它将所有的拥有旧的epoch号的未被commit的proposal清楚。

关于ZXID

         zxid,也就是事务id,为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上zxid。zxid高32位是epoch，低32位为递增计数；epoch：可以理解为当前集群所处的年代或周期，每个leader像皇帝，都有自己的年号，所以每次改朝换代leader变更之后，都会在前一个年代的基础上加1。这样就算旧的leader崩溃之后，也没有人听他的，因为follow只听从当年代的leader的命名。

Leader的选举

leader选举分为两个过程：

启动时候的leader选举，leader崩溃的时候的选举

启动时候的leader选举

       每个节点启动时候都是looking，处于观望状态，接下来就开始进入主流程：进行 Leader 选举，至少需要两台机器我们选取 3 台机器组成的服务器集群为例。在集群初始化阶段，当有一台服务器 Server1 启动时， 它本身是无法进行和完成 Leader 选举，当第二台服务器 Server2 启动时， 这个时候两台机器可以相互通信，每台机器都试图找到 Leader，于是进入 Leader 选举过程。选举过程如下：
        (1) 每个 Server 发出一个投票。由于是初始情况， Server1和 Server2 都会将自己作为 Leader 服务器来进行投票，每次投票会包含所推举的服务器的 myid 和 ZXID、epoch，使用(myid, ZXID,epoch)来表示，此时 Server1的投票为(1, 0)， Server2 的投票为(2, 0)，然后各自将这个投票发给集群中其他机器。
        (2) 接受来自各个服务器的投票。集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票（epoch）、是否来自LOOKING状态的服务器。
       (3) 处理投票。针对每一个投票，服务器都需要将别人的投票和自己的投票进行 PK， PK 规则如下
               i. 优先检查 ZXID。 ZXID 比较大的服务器优先作为Leader

               ii. 如果 ZXID 相同，那么就比较 myid。 myid 较大的服务器作为 Leader 服务器。
              对于 Server1 而言，它的投票是(1, 0)，接收 Server2的投票为(2, 0)，首先会比较两者的 ZXID，均为 0，再比较 myid，此时 Server2 的 myid 最大，于是更新自己的投票为(2, 0)，然后重新投票，对于 Server2 而言，它不需要更新自己的投票，只是再次向集群中所有机器发出上一次投票信息即可。
       (4) 统计投票。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，对于 Server1、Server2 而言，都统计出集群中已经有两台机器接受了(2, 0)的投票信息，此时便认为已经选出了 Leader。
      (5) 改变服务器状态。一旦确定了 Leader，每个服务器就会更新自己的状态，如果是 Follower，那么就变更为FOLLOWING，如果是 Leader，就变更为 LEADING。

运行过程中的 leader 选举
       当集群中的 leader 服务器出现宕机或者不可用的情况时，那么整个集群将无法对外提供服务，而是进入新一轮的Leader 选举，服务器运行期间的 Leader 选举和启动时期的 Leader 选举基本过程是一致的。
        (1) 变更状态。 Leader 挂后，余下的非 Observer 服务器都会将自己的服务器状态变更为 LOOKING，然后开始进入 Leader 选举过程。
       (2) 每个 Server 会发出一个投票。在运行期间，每个服务器上的 ZXID 可能不同，此时假定 Server1 的 ZXID 为123，Server3的ZXID为122；在第一轮投票中，Server1和 Server3 都会投自己，产生投票(1, 123)， (3, 122)，然后各自将投票发送给集群中所有机器。接收来自各个服务器的投票；与启动时过程相同。
(3) 处理投票；与启动时过程相同，此时， Server1 将会成为 Leader。
(4) 统计投票；与启动时过程相同。
(5) 改变服务器的状态；与启动时过程相同。