Zookeeper集群相关与ZAB协议

1024225

今天想总结以下 Zookeeper 集群有关的知识，还有我认为最重要的 ZAB 协议，现在是早上10点，争取12点前弄好，开冲。

Zookeeper 集群

在了解集群前，我觉得有必要先了解下Zookeeper中的事务相关知识。

Zookeeper事务

事务是指能够改变 Zookeeper 服务器状态的操作，比如创建节点，修改节点内容，删除节点内容等操作。
对于每一个事务请求，Zookeeper 都会分配一个全局唯一的事务ID，叫做 ZXID。ZXID 是一个64为数字。

高32为表示的是 Leader 的 epoch，也就是集群的Leader的选举周期，集群每发生一次选举，该值会加1。
低32位表示的是该事务在当前选择周期内的递增次序，Leader 每处理一个事务请求，该值加1，发生一次Leader 选举，低32位要清0。

事务日志

所有的事务操作都是需要记录到日志文件中的，可以通过dataLogDir属性配置事务文件目录，比如下图的
log.200000001和log.100000001都是事务日志文件

[root@abc version-2]# ls
acceptedEpoch  currentEpoch  log.100000001  log.200000001  snapshot.0

Zookeeper提供了shell脚本来给我们查看日志文件，我这里简单截取一下自己服务器的文件内容

[root@abc version-2]# zkTxnLogToolkit.sh log.200000001
/8/20 4:56:08 PM CST session 
5/8/20 7:48:04 PM CST session 0x2028278eb490001 cxid 0x0 zxid 0x200000006 createSession 30000
5/8/20 8:16:57 PM CST session 0x2028278eb490001 cxid 0x2 zxid 0x200000007 create /hh,,[31,s{'world,'anyone}
],true,2
5/8/20 9:02:06 PM CST session 0x2028278eb490001 cxid 0x3 zxid 0x200000008 setData /hh,12,1
5/10/20 9:39:56 AM CST session 0x2028278eb490001 cxid 0x0 zxid 0x200000009 closeSession v{'/hh}

可以看到ZXID 后面的数字是顺序递增的

集群角色

Zookeeper 集群有以下三种角色：

Leader。集群中有且只有一个Leader，通过选举过程产生。负责所有事务写操作，保证集群事务的有序性。默认情况下，Leader 也处理读请求。
Follower。处理客户端的读请求，所有的事务请求都转发给 leader 处理。参与 Leader 的选举投票，参与事务操作的"过半通过策略"。
Observer。只提供读取服务，在不影响写性能的情况下提升集群性能。不参与任何形式的投票。

zookeeper集群通信.png

可以看到Observer与Leader的通信，没有proposal与ack，因为它不参与这个"过半通过策略"，这就节省了网络的开销了，集群性能自然就高一些。

集群数量

最好用奇数台服务器搭建Zookeeper集群，为什么？

这其实是 Zookeeper 的容错决定的，Zookeeper容错是指宕掉几个Zookeeper服务器之后，剩下的个数必须大于宕机的个数才能保证可用。假如有n台 Zookeeper服务器，剩下的服务器个数必须大于n/2。
基于这个前提，举个例子如下

假如我们有3台，那么最大允许宕掉1台zookeeper服务器，如果我们有4台的的时候也同样只允许宕掉1台。
假如我们有5台，那么最大允许宕掉2台zookeeper服务器，如果我们有6台的的时候也同样只允许宕掉2台。

ZAB协议

ZAB协议全称是 Zookeeper Atomic Brocaset （原子广播协议）。是一种支持崩溃恢复的原子广播协议。

ZAB 模式包含两种基本的模式：

崩溃恢复模式
消息广播模式

假如集群一切运行正常，那么ZAB协议就会处于消息广播模式，我们先来看看这个模式下，Zookeeper 集群是怎么工作的。

首先要知道，客户端的所有写请求，都会转发到 Leader 端进行处理。

Leader 会将请求封装成一个事务 Proposal，将其发送给所有的 Follwer，
Follwer会反馈 Ack给 Leader
如果超过半数成功响应，那就进行 commit 操作（先提交自己，任何再发送 commit 给所有 Follower）。

这里就会给每个事务分配一个ZXID。

假如集群的 Leader 宕机了，这时候 ZAB协议就会处于崩溃恢复模式，这个模式下会选举出新的 Leader 服务器，这个过程的大致如下：

Leader election（选举阶段）：节点在一开始处于选举阶段，只要有一个节点得到超过半数节点的票数，它就可以当选准 Leader。
Discovery（发现阶段）：这个阶段，Follower 会跟准 Leader 进行通信，同步 Followers 最近接收的事务提议。
Synchronization（同步阶段）：同步阶段主要是利用 Leader 前一阶段获得的最新提议历史，同步集群中所有的副本。同步完成后准 Leader 才会成为真正的 Leader。
Brocast（广播阶段）：这个阶段，Zookeeper集群才能正式对外提供服务，ZAB协议恢复成消息广播模式。