Zookeeper系列二、Zookeeper原理

1. 扩展性：

        从扩展性开始讲起，在zk中存在的角色有leader，follower，observer。

zk是读写分离的，所有的写都会压到leader上面，读操作可以在follower上面完成。只有follower才能选择，observer比follower级别还低。observer只是为了放大查询能力。

一个集群中投票选举的速度由follower决定。

 

 2. 可靠性

1.  可靠性来自于可以快速恢复，如果leader挂掉之后可以快速恢复，保证集群可用；

2. 对外提供数据的一致性，这里的一致性是弱一致性，采用的最终一致性。最终一致性过程中，节点是否对外提供服务？

3.  Paxos：Zookeeper的灵魂

paxos是一个基于消息传递的一致性算法，paxos被认为是到目前为止唯一的分布式一致性算法。Paxos有一个前提：不存在拜占庭将军问题。也就是假设通信过程不会被篡改。

4.    ZAB协议， Zookeeper Atomic Broadcast（Zk的原子广播协议）

        zab协议是在paxos保证一致性基础上设计出来的高可用协议。ZAB主要用于构建高可用分布式系统，Paxos算法主要用于构建一致性状态机。zab协议包括两种基本的模式：崩溃恢复和消息广播。

      4.1 zab协议的作用：

zk通过zab协议来保证分布式系统的最终一致性：

1. Zab协议是一种支持崩溃恢复的原子广播协议，是zk保证数据一致性的核心算法。

2. 基于zab协议，zk实现了一种主备模型的系统架构来保证集群中各个副本之间数据的一致性。就是指只要一台服务负责处理外部的写请求，然后将数据同步给其他follower节点。

zk客户端会随机的连接到集群中的某一个节点，如果是读请求，就直接从当前节点读取数据；如果是写请求，那么节点就会把请求转发给leader，leader接收到事务会广播该事务，只要超过半数节点写入成功，该事务就会被提交。

---

4.2 zab协议的特性：

1. 确保主节点提交的事务，在从节点也必须提交；

2. 丢弃在主节点上提出但是没有被提交的事务。

---

       

4.3 Zab协议实现的作用 

1. 使用一个单一的进程（leader节点）来接受并处理写请求，采用Zab的原子广播协议将服务器数据的状态变更以事务proposal的形式广播到所有的副本进程中；

2. 保证一个全局的变更序列被顺序引用：

zab要保证同一个leader发起的事务要按照顺序被apply，同时还要保证先前leader的事务被apply之后，新选举出来的leader才能再次发起事务。

3. 当主进程出现异常时，整个集群能够快速恢复，提供高可用。

---

4.4 Zab协议原理：

Zab协议要求每个leader都要经历三个阶段：发现，同步，广播

• 发现： zk集群必须选举出一个leader，同时leader会维护一个follower可用客户端列表。
• 同步： leader负责将本身的数据与follower完成同步，做到多副本存储。这一块体现了CAP中的高可用和分区容错。follower将队列中未处理完的请求消费完成后，写入到本地事务日志
• 广播： leader可以接受客户端新的Proposal请求，将新的Proposal请求广播给所有的follower。

---

4.5 Zab协议写核心——定义了事务请求的处理方式

1）所有的事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被叫做 Leader服务器。其他剩余的服务器则是 Follower服务器。

2）Leader服务器 负责将一个客户端事务请求，转换成一个 事务Proposal，并将该 Proposal 分发给集群中所有的 Follower 服务器，也就是向所有 Follower 节点发送数据广播请求（或数据复制）

3）分发之后Leader服务器需要等待所有Follower服务器的反馈（Ack请求），在Zab协议中，只要超过半数的Follower服务器进行了正确的反馈后（也就是收到半数以上的Follower的Ack请求），那么 Leader 就会再次向所有的 Follower服务器发送 Commit 消息，要求其将上一个 事务proposal 进行提交。

---

4.6 Zab协议内容

协议过程：

当整个集群启动过程中，或者当 Leader 服务器出现网络中弄断、崩溃退出或重启等异常时，Zab协议就会 进入崩溃恢复模式，选举产生新的Leader。

当选举产生了新的 Leader，同时集群中有过半的机器与该 Leader 服务器完成了状态同步（即数据同步）之后，Zab协议就会退出崩溃恢复模式，进入消息广播模式。

这时，如果有一台遵守Zab协议的服务器加入集群，因为此时集群中已经存在一个Leader服务器在广播消息，那么该新加入的服务器自动进入恢复模式：找到Leader服务器，并且完成数据同步。同步完成后，作为新的Follower一起参与到消息广播流程中。

协议状态切换

当Leader出现崩溃退出或者机器重启，亦或是集群中不存在超过半数的服务器与Leader保存正常通信，Zab就会再一次进入崩溃恢复，发起新一轮Leader选举并实现数据同步。同步完成后又会进入消息广播模式，接收事务请求。
 

保证消息有序

在整个消息广播中，Leader会将每一个事务请求转换成对应的 proposal 来进行广播，并且在广播 事务Proposal 之前，Leader服务器会首先为这个事务Proposal分配一个全局单递增的唯一ID，称之为事务ID（即zxid），由于Zab协议需要保证每一个消息的严格的顺序关系，因此必须将每一个proposal按照其zxid的先后顺序进行排序和处理。

---

消息广播

1. 在zk集群中，数据副本的传递策略采用的是消息广播模式。数据同步方式类似于二阶段提交，但是却比二阶段提交性能更高。二阶段提交要求协调者必须等到所有参与者反馈ACK确认消息后，再发送commit消息。要求所有的参与者要么全部成功，要么全部失败。但是这种方式会存在严重的阻塞问题。

2. 在Zab协议中，leader只要等到半数以上的follower成功反馈即可。

消息广播流程图：

消息广播步骤：

1. 客户端发起一个写操作请求；
2.  Leader 服务器将客户端的请求转化为事务 Proposal 提案，同时为每个 Proposal 分配一个全局的ID，即zxid。
3. Leader 服务器为每个 Follower 服务器分配一个单独的队列，然后将需要广播的 Proposal 依次放到队列中取，并且根据 FIFO 策略进行消息发送。
4. Follower 接收到 Proposal 后，会首先将其以事务日志的方式写入本地磁盘中，写入成功后向 Leader 反馈一个 Ack 响应消息。
5. Leader 接收到超过半数以上 Follower 的 Ack 响应消息后，即认为消息发送成功，可以发送 commit 消息。
6. Leader 向所有 Follower 广播 commit 消息，同时自身也会完成事务提交。Follower 接收到 commit 消息后，会将上一条事务提交。

---

崩溃恢复

崩溃恢复主要包括两个部分： Leader选举和数据恢复。

Zab协议如何保证数据一致性：

假设两种异常情况：
        1、一个事务在 Leader 上提交了，并且过半的 Folower 都响应 Ack 了，但是 Leader 在 Commit 消息发出之前挂了。
        2、假设一个事务在 Leader 提交之后，Leader 挂了。

Zab协议需要保证选举出来的Leader需要满足以下条件：

1）新选举出来的 Leader 不能包含未提交的 Proposal 。即新选举的 Leader 必须都是已经提交了 Proposal 的 Follower 服务器节点。
        2）新选举的 Leader 节点中含有最大的 zxid 。这样做的好处是可以避免 Leader 服务器检查 Proposal 的提交和丢弃工作。

 

Zab 如何数据同步：

1）完成 Leader 选举后（新的 Leader 具有最高的zxid），在正式开始工作之前（接收事务请求，然后提出新的 Proposal），Leader 服务器会首先确认事务日志中的所有的 Proposal 是否已经被集群中过半的服务器 Commit。

2）Leader 服务器需要确保所有的 Follower 服务器能够接收到每一条事务的 Proposal ，并且能将所有已经提交的事务 Proposal 应用到内存数据中。等到 Follower 将所有尚未同步的事务 Proposal 都从 Leader 服务器上同步过来并且应用到内存数据中以后，Leader 才会把该 Follower 加入到真正可用的 Follower 列表中。