Zookeeper的几个原理分析

Zookeeper的集群角色

leader

集群的核心
事务请求的唯一调度者和处理者，保证集群事务处理的顺序性
集群内部各个服务器的调度者

follower

处理客户端非事务请求，以及转发事务请求给leader服务器
参与事务请求提议(proposal)的投票
- 客户端的一个事务请求，需要半数服务器投票通过以后才能通知leader commit
- leader会发起一个提案，要求follower投票
参与leader选的投票

observer

Zookeeper3.3以后新增

观察集群中最新状态的变化并将这些状态同步到observer服务器上
增加observer不影响集群中事务处理能力，同时还能提升集群的非事务处理能力

Zookeeper的集群组成

服务器集群数量

一般由2n+1台服务器组成

1台—standalone
多台情况下，集群必须要有过半的机器能够正常工作并且能够正常通信，因为投票要过半。
- 5台必须3台存活，6台也必须3台存活
- 增加了投票的过程，但对可用性并没有提高

leader选举

选举算法

org.apache.zookeeper.server.quorum.QuorumPeer#startLeaderElection

leaderElection
AuthFastLeaderElection
FastLeaderElection
- 默认(org.apache.zookeeper.server.quorum#electionAlg)

源码

源码地址

编译条件
- JDK1.7以上
- Ant
- IDEA

名词

`serverid`

在配置server集群的时候，给定服务器的标识id(myid)

`zxid`

服务器在运行时产生的数据ID，zxid越大，表示数据越新

`Epoch`

选举的轮数

server的状态

Looking
Floowing
Observering
Leading

选举流程

第一次初始化启动的时候状态为：LOOKING

所有在集群中的server都会推荐自己为leader，然后把myid、zxid、epoch作为广播信息，广播给集群总的其它server，并等待其它服务器返回
每个服务器都会接收来自集群中的其它服务器的投票。集群中的每个服务器在接收到投票后，开始判断投票的有效性
- 判断逻辑时钟Epoch
  - 大于自己当前的Epoch，说明自己保存的是过期的。
    - 更新Epoch，同时clear其它服务器发送过来的选举数据。
    - 判断是否需要更新当前自己的选举情况
  - 小于自己当前的Epoch，说明对方的是过期的，也就意味着对方服务器的选举轮数是过期的。这个时候，只需要将自己的信息发送给对象
  - 等于自己当前的Epoch，则根据规则来判断是否有资格获得leader
    - 接收到来自其它服务器的投票后，针对每一个投票，都需要将别人的投票和自己的投票进行PK，ZXID最大的服务器优先。
统计投票
改变服务器状态

st=>start: 选自己当领导
broadcase=>operation: 广播投票信息
looking=>condition: Looking(第一次，第n次)
first=>inputoutput: 第一次
n=>inputoutput: 第n次
resultState=>operation: 投票结果状态
old=>condition: 投票是否过期?
clear=>operation: 清空投票信息
update=>operation: 更新投票信息
record=>operation: 记录投票信息
finish=>operation: 判断投票是否完成
comfirm=>operation: 确认领导
same=>operation: 是否为同一轮
recordOld=>operation: 记录已完成投票
e=>end

st->broadcase->looking->resultState->old
looking(yes)->first->resultState->old
old(yes)->clear->update
old(no)->update->record->comfirm
looking(no)->n->same->recordOld->finish->comfirm
update->record->finish->comfirm

流程图如果无法正常显示，请复制粘贴到支持流程图的编辑器内查看

贰白