理解zookeeper设计原理及ZAB协议和Leader选举

深入了解Zookeeper系列
1.分布式架构存在问题

    问题一：（数据同步问题）

        3台服务器都有数据库链接的配置文件，如果配置更改怎么保证个节点的数组一致性？

    问题二：（任务执行顺序问题）

        三个服务都是相同的，怎么保证一个task任务只在一台服务器（一个节点）上执行？

    问题三:（master选举问题）

        如果其中一个服务器挂了，其他服务器如何发现并接替这个服务器正在执行的任务？

    问题四：（事务一致性问题）

        存在共享资源，对于这个集群每个节点的访问权限是公平的，那么如何保障互斥性、安全性（和多线程安全问题类似）？

     

2.分析问题

       问题出现的原因就是缺少一个分布式协调机制（zookeeper）

 

    引入zookeeper：

    注册zookeeper的节点存在顺序性，按照其发起顺序被应用到zookeeper中去，   最先注册的节点是有优先权的，可以先执行任务,保证了问题二顺序一致性问题。

     

3.zookeeper的设计思想

    1.防止单点故障

        解决方法：

            高可用和高性能的集群方案
            高可用（每个节点都可以分担客户端的请求流量）
            高性能（集群中的某一个节点宕机以后，不影响整个集群的数据和继续提供服务的可能性。）

    2.要实现高可用必须保证每个节点数据的一致性

        解决方法：

                要实现各个节点的数据一致性，就势必要一个 leader 节点负责协调和数据同步操作。

    3.如何举出 leader 节点，leader节点宕机如何恢复数据；

        解决方法：

                zookeeper 用了基于 paxos 理论所衍生出来的 ZAB 协议

    4.如何保证分布式事务一致性（ACID）（leader 节点如何和其他节点保证数据一致性）     

                解决分布式事务的数据一致性协议有 2PC 协议和 3PC 协议。

    结合zookeeper要解决的问题我们基本上知道 zookeeper 为什么要用到 zab 理论来做选举、为什么要做集群、为什么要用到分布式事务来实现数据一致性了。

4.Zookeeper集群

     4.1处理读请求：

        任意节点都可以去处理读请求不需要转发：

    4.2写请求（事务请求）

        会转发给Leader(改进版2pc，过半同意即可)

        1.事务请求发送到follower服务器节点（若发送给Leader节点少了转发这一步）

        2.首先会把事务请求转发给leader，

        3.leader 服务器把客户端的失去请求转化成一个事务 Proposal（提议），并把这个 Proposal 分发给集群中的所有 Follower 服务器，

        4.如果过半的follower节点同意（返回ACK）

        5.Leader 就会再次向所有的Follower 服务器发送 Commit 消息，要求各个 follower 节点对前面的一个 Proposal 进行提交;

        6.把最后的结果同步给Observer节点,

        7.把结果返回给客户端。

    4.3集群角色

        Leader 角色

            Leader 服务器是整个 zookeeper 集群的核心，主要的工作 任务有两项

            1. 事物请求的唯一调度和处理者，保证集群事物处理的顺 序性

            2. 集群内部各服务器的调度者

        Follower 角色

            Follower 角色的主要职责是

            1. 处理客户端非事物请求、转发事物请求给leader 服务器

            2. 参与事物请求 Proposal 的投票（需要半数以上服务器 通过才能通知 leadercommit 数据; Leader 发起的提案，要求 Follower 投票）

            3. 参与 Leader 选举的投票

         Observer 角色

            Observer 是zookeeper3.3 开始引入的一个全新的服务器角色，从字面来理解，该角色充当了观察者的角色。观察 zookeeper 集群中的最新状态变化并将这些状态变化同步到 observer 服务器上。

            Observer 的工作原理与 follower 角色基本一致，而它和 follower 角色唯一的不同在于 observer 不参与任何形式的投票，包括事物请求 Proposal的投票和leader选举的投票。

            注意：observer 服务器只提供非事物请求服务，通常在于不影响集群事物处理能力的前提下提升集群非事物处理的能力

    4.4集群组成

        通常 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 选举算法。同时也涉及到事务请求的提交投票

        之所以要满足这样一个等式，是因为一个节点要成为集群中的 leader，需要有超过及群众过半数的节点支持，这个涉及到 leader 选举算法。同时也涉及到事务请求的提交投票

5.ZAB协议（原子消息广播协议）

    ZAB（Zookeeper AtomicBroadcast）协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。在 ZooKeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性，

    5.1ZAB 协议的核心定义;

        当整个集群在启动时，或者当 leader 节点出现网络中断、崩溃等情况时，ZAB 协议就会进入恢复模式并选举产生新的 Leader，当 leader 服务器选举出来后，并且集群中有过半的机器和该 leader 节点完成数据同步后（同步指的是数据同步，用来保证集群中过半的机器能够和 leader 服务器的数据状态保持一致），ZAB 协议就会退出恢复模式。当集群中已经有过半的 Follower 节点完成了和 Leader 状态同步以后，那么整个集群就进入了消息广播模式。这个时候，在 Leader 节点正常工作时，启动一台新的服务器加入到集群，那这个服务器会直接进入数据恢复模式，和 leader 节点进行数据同步。同步完成后即可正常对外提供非事务请求的处理。

        有定义可知ZAB协议主要有两种模式

            1.消息广播模式

            2.数据恢复模式

    5.2消息广播的实现原理

    消息广播存在事务处理过程中（改良版本的2pc）：

        1. Leader 接收到消息请求后，将消息赋予一个全局唯一的64 位自增 id，叫：zxid，通过 zxid 的大小比较既可以实

        现因果有序这个特征；

        2. Leader 为每个 follower 准备了一个 FIFO 队列（通过 TCP协议来实现，以实现了全局有序这一个特点）将带有 zxid的消息作为一个提案（proposal）分发给所有的 follower；

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

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

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

             

 

    5.3崩溃恢复(数据恢复)

    ZAB 协议的这个基于原子广播协议的消息广播过程，在正 常情况下是没有任何问题的，但是一旦 Leader 节点崩溃，或者由于网络问题导致 Leader 服务器失去了过半的 Follower 节点的联系（leader 失去与过半 follower 节点联系，可能是 leader 节点和 follower 节点之间产生了网络分区，那么此时的 leader 不再是合法的 leader 了），那么就 会进入到崩溃恢复模式。

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

            当 leader 收到合法数量 follower 的 ACKs 后，就向各个 follower 广播 COMMIT 命令，同时也会在本地执行 COMMIT 并向连接的客户端返回「成功」。

            如果在各个 follower 在收到 COMMIT 命令前Leader 就挂了，导致剩下的服务器并没有执行都这条消息。

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

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

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

            如图：在集群正常运行过程中的某一个时刻,Leader节点先后广播P1,P2,C1,C2；其中当Leader服务器将消息P2提交后，就立即崩溃推出。这种情况下当崩溃的服务器再起链接的时候C1和C2事务将会被抛弃删除。

             

6.leader选举算法

    能够确保已经被leader 提交的事务 Proposal能够提交、同时丢弃已经被跳过的事务Proposal

    6.1重要的几个概念

     SID：服务器ID

          用SID来唯一标识Zookeeper集群中的机器，每台机器都不能重复，和myid的值一致。

     ZXID：事务ID

        ZXID是一个事务ID，用来唯一标识一次服务器状态的变更。在某一个时刻，集群中每台机器的ZXID指不一定都一致。ZXID由2部分组成zxid是 64 位，高 32 位是 epoch 编号 低 32 位是counter消息计数器；

        epoch：可以理解为当前集群所处的年代或者周期，每个leader 就像皇帝，都有自己的年号，所以每次改朝换代，leader 变更之后，都会在前一个年代的基础上加 1。这样就算旧的 leader 崩溃恢复之后，也没有人听他的了，因为follower 只听从当前年代的 leader 的命令。

                counter消息计数器:每接收到一条事务消息这个值就+1

当处理事务请求时，会先成一个事务ID（ZXID）如图，同一个Leader的统治下epoch是相同的，counter消息计数器随着事务的增加而递增，会按照请求顺序转发给Leader，并保存在一个FIFO队列中，这样就可以保证事务的顺序一致性。同时当这个Leader挂了，新选举出的Leader的epoch会+1，这样当这个节点在链接上来的时候，未处理的事务由于epoch过期了全部清除过期的事务
7.Leader 选举

    Leader 选举会分两个过程：

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

    7.1服务器启动时的 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

                如果 leader 选举算法能够保证新选举出来的 Leader 服务器拥有集群中所有机器最高编号（ZXID 最大）的事务Proposal，那么就可以保证这个新选举出来的 Leader 一定具有已经提交的提案。因为所有提案被 COMMIT 之前必须有超过半数的 follower ACK，即必须有超过半数节点的服务器的事务日志上有该提案的 proposal，因此，只要有合法数量的节点正常工作，就必然有一个节点保存了所有被 COMMIT 消息的 proposal 状态

            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。

    7.2运行过程中的 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) 改变服务器的状态。与启动时过程相同

————————————————
版权声明：本文为CSDN博主「zpoison」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/zpoison/article/details/80615468