Zookeeper 的核心原理

Zookeeper 的由来

1. 各个节点的数据一致性

2. 怎么保证任务只在一个节点执行

3. 如果orderserver1挂了，其他节点如何发现并接替

4. 存在共享资源，互斥性、安全性

 

Apache 的Zookeeper

Google 的Chubby 是一个分布式锁服务，通过Google Chubby 来解决分布式协作、Master选举等与分布式锁服务相关的问题

 

Zookeeper 的设计猜想

1. 防止单点故障

   1. 集群方案（Leader Follower）还能分担请求，既做了高可用，又做高性能

2. 每个节点的数据是一致的（必须要有leader）

   leader master（带中心化的） redis-cluser （无中心化的）

3. 集群中的leader 挂了，怎么办？数据怎么恢复？

   选举机制？数据恢复

4. 如何去保证数据一致性？(分布式事务)

   2PC 协议、二阶提交

2PC

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

阶段一：提交事务请求

1. 事务询问

   1. 协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。

2. 执行事务

   1. 各个参与者节点执行事务操作，并将Undo和Redo信息记录到事务日志中，尽量把提交过程中所有消耗时间的操作和准备的提前完成确保后面100%成功提交事务

3. 各个参与者向协调者反馈事务询问的响应

   1. 如果各个参与者都成功执行了事务操作，那么就反馈给参与者yes的响应，表示事务可以执行；

   2. 如果参与者没有成功执行事务，就反馈给协调者no的响应，表示事务不可以执行；

   3. 2pc 协议的第一个阶段称为“投票阶段”，即各参与者投票表名是否需要继续执行接下去的事务提交操作。

阶段二：执行事务提交

在这个阶段，协调者会根据各参与者的反馈情况来决定最终是否可以进行事务提交操作；

两种可能：

• 执行事务

• 中断事务

 

Zookeeper 的集群角色

在zookeeper中，客户端随机连接到zookeeper中的一个节点。

如果是读请求，就直接从当前节点中读取数据

 

如果是写请求，那么请求会转发给leader 提交事务，然后leader将事务广播给集群中的follower节点（注意obeserver节点不参与投票），Follower 节点给leader 一个ack (ack表示当前的节点是不是能执行这个事务)，只要有超过半数节点写入成功，那么写请求就会被提交。集群节点需要（2n+1）

Leader 角色

是zookeeper中的整个核心，起到了主导整个集群的作用

1. 事务请求的调度和处理

2. 保证事务处理的顺序性

Follower角色

1. 处理客户端的非事务请求，

2. 转发事务请求给leader服务器

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

4. 参与leader节点选举的投票

Observer角色

是一个观察者角色

1. 了解集群中的状态变化 ，和对这些状态进行同步

2. 工作原理和follower节点一样，唯一差别是不参与事务请求的投票，不参与Leader选举

3. Observer 只提供非事务请求，通常在于不影响集群事务处理能力的前提下，提升集群非事务处理能力

注：

为什么需要2n+1节点

表示奇数节点， zookeeper中要正常对外提供服务的话，它里面有个投票机制，这个机制就是必须要有过半的机器正常工作，并且能够彼此完成通信进行事务投票结果。

ZAB协议

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

ZAB

支持崩溃恢复的原子广播协议，主要用于数据一致性

ZAB协议基本模式

• 崩溃恢复（恢复leader节点和恢复数据）

• 原子广播

消息广播的实现原理

消息广播过程实际是一个简化版的二阶提交。2PC

1. leader 接收到消息请求后，将消息赋予一个全局唯一的64位自增id（ZXID）。ZXID大小，实现因果有序的特征。

2. leader 为每一个follower 准备了一个FIFO队列，将带有zxid的消息作为一个提案（Proposal）分发给所有follower

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

4. 当leader接收到合法数量的ack后，leader 就会向这个follower 发送commit命令，同时会在本地执行该消息。

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

注：leader 的投票过程，不需要Observer 的ack,但是Observer必须要同步Leader的数据，保证数据的一致性。

崩溃恢复

1. 当leader失去了过半的follower节点的联系

2. 当leader服务器宕机

集群进去崩溃恢复阶段

对于数据恢复来说

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

   1. 当leader 收到合法数量的follower 的ack以后，就会向各个follower 广播消息（commit命令），同时自己也会commit 这条事务消息。

   2. 如果follower节点收到commit命令之前，leader挂了，会导致部分节点收到commit,部分节点没有收到。

   3. ZAB协议需要保证已经处理的消息不能丢失。

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

3. 当Leader收到事务请求，还未发起事务投票之前，leader挂了

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

ZAB的设计思想

1. zxid 是最大的

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

2. epoch的概念，每产生一个新的leader,那么新的leader的epoch会+1,zxid 是64位的数据，低32位表示消息计数器（自增），每收到一条消息，这个值+1，新 leader选举后这个值重置为0。这样设计的原因在于，老的leader 挂了以后重启，他不会选举为leader,y因此此时它的zxid肯定小于当前新的l