Zookeeper入门基础理论

目录

• Zookeeper简介
• ZAB协议
  1. ZAB协议简介
  2. 消息广播
  3. 崩溃恢复
  4. 数据同步

---

1、Zookeeper简介

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

2、ZAB协议

2.1 ZAB协议简介

ZAB协议全称“Zookeeper Atomic Broadcast”(Zookeeper原子广播协议)。是专为分布式协调服务Zookeeper设计的一种支持原子广播和崩溃恢复设计的协议，基于它，Zookeeper实现一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。

上图显示的就是Zookeeper实现集群中的数据一致性的原理。主进程（Leader）和备份进程（Follower）。

2.2 消息广播

类似二阶段提交。时序图如下：

说明：

• Leader收到客户端请求后，会将请求封装成一个事务，并给事务分配一个全局递增的唯一ID（ZXID），ZAB协议需要保证事务的顺序，每个事务必须按照ZXID先排序再处理
• 为保证集群中所有进程有序的顺序执行，只能Leader接受写请求，Follower收到写请求也会转发给leader处理

基本上就是三步骤：

问题？
广播中，Leader发出复制数据给所有Follower后，崩溃啦，咋办？如果Leader收到超过半数的ACK先提交啦，可给Follower的部分提交请求发送出去后崩溃啦，咋办？

2.3 崩溃恢复

针对上面广播可能产生的问题，ZAB定义了两个原则，设计了一个选举算法。

• 原则：
  1、Leader已经提交了的事务，最终会被所有服务器提交
  2、Leader只提出复制，并未提交的事务，都将丢弃

• 选举算法：
  保证新选举出来的Leader服务器拥有集群最大的事务ID（ZXID），保证新Leader一定具有所有已经提交的提案。

问题？
崩溃恢复之后，如何保证数据的准确性？

2.4 数据同步

支持崩溃恢复后数据准确性的就是数据同步了，数据同步基于事务的 ZXID 的唯一性来保证。实际上，Leader 服务器处理或丢弃事务都是依赖着 ZXID 。

ZXID：ZXID 是一个64位的数字，其中低32位可以看作是一个简单的递增的计数器，针对客户端的每一个事务请求，Leader 都会产生一个新的事务 Proposal 并对该计数器进行+1操作。而高32位则代表了 Leader 服务器上取出本地日志中最大事务 Proposal 的 ZXID，并从该 ZXID 中解析出对应的 epoch 值，然后再对这个值+1

高 32 位代表了每代 Leader 的唯一性，低 32 代表了每代 Leader 中事务的唯一性。同时，也能让 Follwer 通过高 32 位识别不同的 Leader

当 Follower 链接上 Leader 之后，Leader 服务器会根据自己服务器上最后被提交的 ZXID 和 Follower 上的 ZXID 进行比对，比对结果要么回滚，要么和 Leader 同步。

参考：https://www.cnblogs.com/veblen/p/10985676.html