Zookeeper集群
集群角色
- Leader:领导者
写操作的唯一调度者和处理者,保证集群事务处理的顺序性。
集群内部各个服务器的调度者。
对于所有涉及写操作和更新操作的请求,要统一转发给leader处理。
- Follower:跟随者
处理读操作请求,可以直接响应读请求。
转发写请求给Leader
参与集群Leader选举投票
- Observer:观察者
处理读操作请求,可以直接响应读请求。
转发写请求给Leader
不参与提交和选举投票
提升集群的读性能;可以跨数据中心部署(如北京和香港都使用Zookeeper集群,Leader在北京,如果香港的节点是Follower,写操作会同步Follower,延迟较高,可以将香港节点设置为Observer,不参与选举,不参与投票,仅处理读请求)
集群架构
leader节点可以处理 读写请求,follower只可以处理读请求。follower在接收到写请求时,会把写请求转发给leader处理。
Zookeeper数据一致性保证:
- 全局可线性化写入:先到达leader的写请求会被先处理,leader决定写请求的执行顺序。
- 客户端FIFO顺序:来自给定客户端的请求按照发送顺序执行。
Leader选举原理
Zookeeper的Leader选举存在两个阶段:服务启动时的Leader选举、运行过程中leader宕机。
在分析选举原理前,介绍几个重要的参数:
- 服务器ID(myid):编号越大在选举算法中的权重越大
- 事务ID(zxid):值越大说明数据越新,权重越大
- 逻辑时钟(epoch-logiclclock):同一轮投票中的逻辑时钟是相同的,每投完一次值会增加。
选举状态:
- LOOKING:竞选状态
- FOLLOWING:随从状态,同步leader数据,参与投票
- OBSERVING:观察状态,同步leader数据,不参与投票
- LEADING:领导者状态
服务器启动时
每个节点启动的时候都进入LOOKING观望状态
- 第一台服务器server1启动,进入LOOKING观望状态,无法进行leader选举
- 第二台服务器server2启动,进入LOOKING状态,此时两台机器可以通信,开始进行leader选举
- 每台server发出一个投票,都是投自己。
- 将自己的投票发送给集群的其他机器。
- 接收到来自各个服务器的投票后,首先校验该投票的有效性, 如检查是否本轮投票(epoch)、是否来自LOOKING状态的机器。
- 处理收到的其他server的投票。针对每一次投票,都将其他服务器的投票和自己的投票进行对比,对比规则:
- 优先比较epoch
- 检查zxid,zxid比较大的服务器优先作为leader
- 如果zxid相同,那么比较myid,myid较大的服务器作为leader服务器
- 统计投票。每轮投票后,服务器统计投票信息,判断是否有过半机器收到相同的投票信息。
- 改变服务器状态。一旦确定了Leader,每个服务器响应更新自己的状态。如果是follower,那么变更为FOLLOWING,如果是leader,状态更改为LEADING。此时server3继续启动,直接加入,变更自己的状态为FOLLOWING。
运行过程中
当集群中leader服务器出现宕机或者不可用情况时,整个集群无法对外提供服务,进入新一轮的leader选举。
- 变更状态。leader挂后,所有非observer服务器将自身服务器的状态修改为LOOKING。
- 每一个server发出一个投票。在运行期间,每个服务器上zxid可能不同。
- 处理投票,规则和启动过程相同。
- 统计结果。与启动过程规则相同。
- 改变服务器状态。与启动过程相同。
数据同步流程
在Zookeeper中,主要依赖ZAB协议来实现分布式数据一致性。
ZAB协议分为两部分:消息广播、崩溃恢复。
消息广播
Zookeeper使用单一的主进程Leader来接收和处理客户端所有事务请求,并采用ZAB协议的原子广播协议,将事务请求以Proposal提议广播到所有的Follower节点,当集群中有半数以上的Follower节点进行了正确的ACK反馈,那么Leader就会向所有的Follower服务器发送commit消息,将此提案进行提交。这个过程可以简称为2pc事务提交,流程如下图:
Observer节点只负责同步Leader数据,不参与2PC数据同步过程。
崩溃恢复
在正常情况消息下广播能运行良好,但是一旦Leader服务器出现崩溃,或者由于网络原理导致Leader服务器失去了与过半的Follower的通信,那么就会进入崩溃恢复模式,需要选举出一个新的Leader服务器。在这个过程中可能会出现两种 数据不一致的隐患,需要通过ZAB协议的特性进行避免。
- Leader服务器刚提出proposal后,立即崩溃
- Leader服务器将消息commit发出后,立即崩溃
ZAB协议的恢复模式使用了以下策略:
- 选举zxid最大的节点作为新的leader
- 新leader将事务日志中尚未提交的消息进行处理