1. Leader
Leader 在集群中主要完成:
1. 集群中的所有事务 Request 都将通过 Leader 来进行处理, 而leader 将 Request 发送给所有 leader&follower 经过半数 ACK 回应之后 Leader 才会正真执行 Request
2. lead操作(方法 leader.lead())
3. 使用 LearnerCnxAcceptor 监听端口, 监听 Follower/Observer 进行连接, 会为每个 Follower/Observer 创建一个 LearnerHandler, LearnerHandler在集群中处于非常重要的地位, 处理 与 Follower/Observer 之间的消息接收发送, Leader/Follower建立, 数据同步(主要方法在 sendPackets, run 里面)
2. Follower
Follower 在集群中主要完成:
1. 集群中的所有发给Follower的事务 Request都会发给 Leader, 而leader 将 Request 发送给所有 leader&follower 经过半数 ACK 回应之后 Leader 才会正真执行 Request
2. 连接 leader(connectToLeader), 与 Leader 数据同步(syncWithLeader), 读取Leader发来的数据包 (readPacket), 处理Leader发来的数据包(processPacket)
3. Observer
Observer 在集群中主要完成:
Observer完成Follower的所有事情, 除了 参与 "事务 Request的过半 ACK才 commit" 这个事务操作
4. QuorumPeer
QuorumPeer 在集群中主要完成:
1. 在集群启动过程中, 确定自己在集群中的角色(leader/Follower/Observer), 主要方法在 run()
2. 根据配置文件创建对应的集群Leader选举算法 (默认是 FastLeaderElection)
3. 从磁盘中加载数据, 这里面涉及 Snapshot, Txnlog 文件的处理(这些操作会在 ZKDatabase部分详细解说)
4. 初始化出 lastProcessedZxid(本节点处理的最后一个 zxid), currentEpoch(当前节点已经参与Leader选举的 Epoch值), acceptedEpoch(已经接收到leader选举的Epoch值)
5. ZooKeeperServer
ZooKeeperServer 在集群中主要完成:
1. processTxn 处理集群里面的 Request(调用的就是 ZKDatabase().processTxn(hdr, txn))
2. processPacket 处理 zkClient 发来的消息(消息的来源是: NIOServerCnxnFactory.run -> NIOServerCnxn -> doIO -> readPayload -> readRequest/readConnectRequest(其中的 initialized 决定))
3. processConnectRequest 处理 zkClient 的初次连接操作(包括 sessionTimeout的初始化及创建 createSession, 其中有个注意点, LeaderZooKeeperServer与FollowerZooKeeperServer处理 createSession 的流程是不一样的, 正真的 SessionImpl 都是在 leader上存储, Follower 上只存储 sessionId <-> sessionTimeOut)
4. submitRequest 提交 request , 每次提交时都会出发 touchSession(session)操作, 这个 touchSession 在Leader 方将进行触发 session超时机制, 后面会详细解说
6. LeaderZooKeeperServer
LeaderZooKeeperServer在集群中主要完成:
1. LeaderZooKeeperServer 主要代表着 集群中的 leader
2. 构建对应的 RequestProcesser 链, 关于这一部分, 后续会详讲解
3. 下面是 Leader 的 RequestProcessor 处理链
第一条 RequestProcessor 链
PreRequestProcessor : 创建和修改 TxnRequest
ProposalRequestProcessor : 提交 Proposal 给各个 Follower 包括 Leader自己 (Leader自己是在 ProposalRequestProcessor 里面通过 syncProcessor.processRequest(request) 直接提交 Proposal)
CommitProcessor : 将 经过集群中的过半 Proposal 提交(提交的操作直接在 Leader.processAck -> zk.commitProcessor.commit(p.request))
ToBeAppliedRequestProcessor: 这个处理链其实是 Request 处理时经过的最后一个 RequestProcessor, 其中最令人困惑的是 toBeApplied, 而 toBeApplied 中其实维护的是 集群中经过 过半 ACK 同意的 proposal, 只有经过 FinalRequestProcessor 处理过的 Request 才会在 toBeApplied 中进行删除
FinalRequestProcessor: 前面的 Request 只是在经过 SynRequestProcessor 持久化到 txnLog 里面, 而 这里做的就是真正的将数据改变到 ZKDataBase 里面
第二条 RequestProcessor 链
在 leader 中, SynRequestProcessor, AckRequestProcessor 的创建其实是在 ProposalRequestProcessor 中完成的
SynRequestProcessor: 主要是将 Request 持久化到 TxnLog 里面, 其中涉及到 TxnLog 的滚动, 及 Snapshot 文件的生成
AckRequestProcessor: 主要完成 针对 Request 的 ACK 回复, 对 在Leader中就是完成 leader 自己提交 Request, 自己回复 ACK
PrepRequestProcessor --> ProposalRequestProcessor --> CommitProcessor --> ToBeAppliedRequestProcessor --> FinalRequestProcessor
\
SynRequestProcessor --> AckRequestProcessor (这条分支是在 ProposalRequestProcessor 里面进行构建的)
3. registerJXM/unregisterJMX
7. FollowerZooKeeperServer
FollowerZooKeeperServer在集群中主要完成:
1. FollowerZooKeeperServer 在集群中代表着 Follower
2. 构建 属于 Follower 的 RequestProcessor
3. 下面是 Follower 的RequestProcessor 链
第一条 链
FollowerRequestProcessor: 区分处理 Request, 将 Request 交由下个 RequestProcessor, 而若涉及事务的操作, 则 交由 Follower 提交给 leader (zks.getFollower().request())
CommitProcessor: 这条链决定这着 Request 能否提交, 里面主要有两条链 , queuedRequests : 存储着 等待 ACK 过半确认的 Request, committedRequests :存储着 已经经过 ACK 过半确认的 Request
FinalRequestProcessor: 前面的 Request 只是在经过 SynRequestProcessor 持久化到 txnLog 里面, 而 这里做的就是真正的将数据改变到 ZKDataBase 里面(作为 Follower 一定会在 FollowerZooKeeperServer.logRequest 进行同步Request 数据到磁盘里面后再到 FinalRequestProcessor)
第二条 链
SynRequestProcessor: 主要是将 Request 持久化到 TxnLog 里面, 其中涉及到 TxnLog 的滚动, 及 Snapshot 文件的生成
AckRequestProcessor: 主要完成 针对 Request 的 ACK 回复, 对 在Leader中就是完成 leader 自己提交 Request, 自己回复 ACK
1. FollowerRequestProcessor --> CommitProcessor --> FinalRequestProcessor
2. SyncRequestProcessor --> SendAckRequestProcessor
8. ObserverZooKeeperServer
ObserverZooKeeperServer 和 FollowerZooKeeperServer 差不多, 就是不参与 Request ACK投票
9. 总结
ZooKeeper 的源码虽然少, 但其中有几个流程涉及的交互比较多, 本篇主要是让读者知道 ZooKeeper 集群中各个参与者的角色, 以便于后续理解其 Leader选举, Leader/Follower 建立过程, 事务操作等等
参考:
leesf456 ZooKeeper 源码分析
vinowan ZooKeeper 源码分析
陶邦仁 ZooKeeper 源码分析
乒乓狂魔 ZooKeeper 源码分析
desehawk ZooKeeper 源码分析
