聊聊分布式架构10——Zookeeper入门详解

所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为Leader服务器，而余下的其他服务器则成为Follower服务器。Leader服务器负责将一个客户端事务请求转换为一个事务Proposal（提议），并将该Proposal分发给集群中的所有Follower服务器。之后Leader服务器需要等待所有Follower服务器的反馈，一旦超过半数的Follower服务器进行了正确的反馈后，那么Leader就会再次向所有的Follower服务器发布Commit信息，要求将前一个Proposal进行提交。

ZAB协议基本模式

ZAB 协议包括两种基本模式：消息广播和崩溃恢复。

消息广播：这是 ZAB 协议的基本模式之一，用于确保 ZooKeeper 集群中的所有节点都接收到相同的消息。在这种模式下，ZooKeeper 集群中的 leader 节点负责将客户端请求转化为一系列的消息，然后将这些消息广播给所有的 follower 节点。每个 follower 节点接收到消息后，会将消息写入本地的事务日志。一旦超过半数的节点确认接收了消息，leader 就可以提交这些消息，并将其应用到自己的状态机上，从而达到状态一致性。这确保了 ZooKeeper 的一致性和可靠性。
崩溃恢复：是 ZAB 协议的另一种基本模式，用于选择 ZooKeeper 集群中的 leader 节点。在一个 ZooKeeper 集群中，只有一个节点充当 leader，负责处理客户端请求并维护共享状态。如果当前的 leader 节点出现故障，集群需要选举一个新的 leader。ZAB 协议中的选举是基于消息广播的，节点会争相发送选举消息，然后根据规则选择新的 leader。选举过程确保了只有一个节点成为 leader，从而维持了一致性。

消息广播

ZAB的消息广播类似于二阶段提交。不同之处是ZAB协议移除了中断逻辑------Follower服务器要么Ack给Leader，要么抛弃Leader。当过半的Follower服务器反馈Ack之后就开始提交事务Proposal,而不需要等待集群中所有的Follower服务器都反馈响应。

消息广播是基于具有FIFO特性的TCP协议通信的，所以能很容易地保证消息广播过程中消息接收与发送的顺序性。
整个消息广播过程中，leader服务器会为每一个事务请求生成一个Proposal来进行广播，并且在广播事务Proposal之前，Leader服务器会为这个事务分配一个全局单调递增的唯一ID,称之为事务ID(即ZXID)。而且每一个事务Proposal严格按照其ZXID的先后顺序进行排序和处理。
消息广播过程中，Leader服务器会为每一个Follower服务器各自分配一个单独的队列，将需要广播的事务Proposal一次放入队列中，根据FIFO的策略发送。每一个Follower服务器在接收到这个事务Proposal之后，都会首先将其以事务日志的形式写入本地磁盘，在成功写入后反馈给Leader服务器一个Ack响应。服务器收到过半的Follower的Ack响应后，就会广播一个Commit消息给所有的服务器以通知其进行事务提交，同时Leader完成自身的事务提交，每一个Follower服务器收到Commit消息后，完成自身事务的提交。

需要注意的是：Leader服务器可以处理事务请求(包括创建、更新和删除节点等需要保证强一致性的操作)和非事务请求，Follower服务器只能处理非事务请求，如果Follower收到事务请求会转交给Leader服务器。

崩溃恢复

简化的二阶段提交模型是无法处理Leader崩溃带来的数据不一致问题。一旦Leader服务器出现崩溃，或者由于网络导致Leader服务器失去了过半Follower的联系，就会进入崩溃恢复模式。

崩溃恢复状态下，ZAB协议有两件事要做：

选举出新的Leader服务器
数据同步

选举出新的Leader服务器

整个崩溃过程结束后，需要选举出新的Leader服务器，而且还得让其他服务器感知到选举产生的新Leader服务器。

在ZAB协议中，崩溃恢复模式可能出现的两个数据不一致的隐患场景：

服务器Leader在确认半数通过后完成了进行自身事务的提交，但是发送Commit告知Follower进行事务提交的瞬间异常，这是第一个需要保证的特性：确保在Leader服务器提交过的事务最终被所有服务器都提交。
ZAB协议规定：如果一个Proposal事务在一台机器上被处理成功，那么应该在所有的机器上都被处理成功，哪怕机器出现故障崩溃。(所以在过半确认过程中数据会被强制一致的)基于这个特性，如果Leader节点在提出了某个Proposal事务之后就崩了，没有告知到Follower进行本地提交，等崩溃恢复了，原本的Leader保留了提出这个Proposal的状态，此时应该直接丢弃而不是强制同步。这是第二个需要保证的特性：确保丢弃那些只在Leader服务器上被提出的事务。

结合这两种情况，ZAB协议设计的选举算法就必须要满足：能够确保提交已经被Leader提交的事务Proposal，同时丢弃已经被跳过的事务Proposal。

ZAB协议的Leader选举方案就是：拥有最大ZXID的Follower服务器作为新的Leader服务器。为什么呢？

在消息广播的过程中，Leader服务器进行自身事务的提交前提是收到了半数的Follower服务器的Ack响应，那么此时必然有Follower服务器的事务日志中保存了所有的proposal状态，包含Leader异常时提交的那份。
Follower自身ZXID是64位，高32位是epoch编号，低32位是消息计数器，每接收到1条消息+1，新Leader选举后epoch会+1，消息计数器置为0。设计的好处在于，旧的Leader作为Follower接入时，它的ZXID是肯定小于新Leader的，而且新Leader会让它将所有的拥有旧的epoch号的未被Commit的proposal清除。

至此，就保证了崩溃恢复后数据的一致性。

数据同步

在选出新的Leader服务器后，需要开始数据同步。Leader服务器会为每一个Follower服务器准备一个队列，将那些没有被同步的事务以Proposal消息的形式逐个发给Follower服务器，在Follower服务器将所有未同步的proposal事务从Leader服务器上同步并成功应用到本地数据库中后，Leader服务器会将该Follower服务器加入真正可用的Follower列表中，然后开始之后的正常流程。

02Zookeeper的核心

ZooKeeper是一个开源的分布式协调服务，用于构建分布式应用和分布式系统。它提供了一个高度可靠的分布式协调基础设施，帮助应用程序在分布式环境中协同工作。ZooKeeper 通常用于解决分布式系统中的一致性、配置管理、锁服务、命名服务等问题。

ZooKeeper 的核心特点

分布式文件系统：ZooKeeper 维护一个分层的命名空间，类似于文件系统目录结构，它可以用于存储配置信息和分布式数据。
一致性：ZooKeeper 提供了强一致性的数据模型，即一旦数据被写入，所有客户端都能读取到最新的数据，从而确保数据的一致性。
高可用性：ZooKeeper 以多数节点的方式运行，即在集群中的节点数必须超过半数，以确保高可用性。如果一些节点失效，ZooKeeper 仍然能够提供服务。
快速通知：ZooKeeper 允许客户端监听节点数据的变化，一旦节点数据发生变化，相关的客户端将得到通知。
顺序一致性：ZooKeeper 允许客户端按照顺序创建节点，并提供了有序性保证，这在分布式锁服务中非常有用。

ZooKeeper 的核心组件

集群：ZooKeeper 集群由多个节点组成，这些节点分布在不同的机器上，它们协同工作以提供服务。典型的 ZooKeeper 集群包括奇数个节点，通常是 3、5 或 7 个节点，以确保多数节点可用。
ZNode：ZNode 是 ZooKeeper 命名空间的基本单元，类似于文件系统中的目录或文件。每个 ZNode 可以包含数据，并具有一个路径名称。
会话：ZooKeeper 客户端与 ZooKeeper 服务器之间建立会话，会话是客户端与服务器之间的状态会话，用于保持连接和跟踪会话的生命周期。
Watch：客户端可以在 ZNode 上设置 Watch，以便在 ZNode 数据发生变化时获得通知。
选举算法：ZooKeeper 使用选举算法来选举 leader 节点，leader 负责协调事务和保持一致性。

选举算法概述

分两种情况拆解下选举算法：服务器启动时的Leader选举和服务器运行期间的Leader选举。

服务器启动时的Leader选举

假设在集群中，有3台服务器已经可以互相通信，它们需要选出一个Leader服务器。有一个前提条件，它们拥有一个myid的属性，server1的myid是1，server2的myid是2，server3的myid是3。

1.每个server会发出一个投票

例如server1以(myid，zxid)格式发送给其他服务器投票的数据(1,0)，server2发送的(2,0)。

2.接收来自每个服务器的投票

每个服务器都会收到其他服务器的投票，首先验证有效性，其次是否本轮投票、是否来自Looking状态的服务器。

3.处理投票

每个服务器根据规则处理收到的投票，规则如下：

优先zxid。zxid大的优先作为Leader。
zxid相同，myid大的作为Leader。

那么，3台服务器的zxid都为0，就会比较myid。server1和server2根据规则会修改自身投票为(3,0)。然后重新向其他服务器发送投票。server3不用修改，只是再发送一次。

4.统计投票

每次投票，服务器都会统计所有投票判断是否产生了Leader，这里还是使用的过半概念：当有一半的服务器收到相同的投票时候，就认为已经选出了Leader。

5.改变服务器状态

一旦确定了Leader，服务器就会变更自己的状态：Follower会变更为FOLLOWING，Leader会变更为LEADING。

服务器运行期间的Leader选举

当Leader服务器挂掉的时候，就会进行新一轮的Leader选举。

1.变更状态

非Observer服务器会将自己的服务器状态变更为LOOKING，开始选举流程。(Observer服务器不参与选举也不投票)

2.每个server发出一个投票

与启动期间不同的是，运行期间的服务器可能有不同的zxid。例如server的投票(1,1112)，server3的投票(3,1113)。

3.接收各个服务器的投票

4.处理投票，显然server3的zxid大，server3会成为Leader。

5.统计投票

6.改变服务器状态

03ZooKeeper的简单使用

可以参考这篇博客：http://t.csdnimg.cn/N6yyU

04ZooKeeper的应用场景

Apache ZooKeeper 在分布式系统中有多种典型应用场景，它提供了高度可靠的分布式协调服务，用于解决各种分布式系统的共识、配置管理和协同协作问题。以下是 ZooKeeper 的一些典型应用场景：

分布式配置管理：ZooKeeper 可用于存储和管理应用程序的配置信息。各个分布式节点可以监听配置节点，当配置发生变化时，节点能够及时获取最新的配置，实现动态配置管理。
分布式锁服务：ZooKeeper 提供了分布式锁服务，允许多个节点协同竞争获取锁。这对于协调分布式系统中的操作非常有用，确保只有一个节点能够执行关键操作。
分布式一致性：ZooKeeper 可以用于协调多个节点以达成一致的决策。它确保在分布式系统中节点的状态和数据是一致的，从而提供强一致性的数据存储。
服务发现：ZooKeeper 可用于注册和发现分布式系统中的服务。各个服务可以在 ZooKeeper 上注册自己的地址和状态，其他节点可以查询这些信息以发现可用的服务。
领导者选举：ZooKeeper 通常用于选举分布式系统中的领导者节点。它确保只有一个节点成为领导者，从而协调系统的操作。
分布式任务队列：ZooKeeper 可用于创建分布式任务队列，多个节点可以将任务推送到队列中，然后从队列中获取任务进行处理。
分布式协同协作：ZooKeeper 提供了分布式协调服务，可以用于构建分布式应用程序，确保多个节点协同协作并实现一致性。
分布式文件系统：虽然 ZooKeeper 不是一个文件系统，但它可以用于管理分布式系统中的文件和配置信息，作为分布式文件系统的一部分。

参考资料：从Paxos到Zookeeper 分布式一致性原理与实践 [倪超著]