zookerper集群Leader选举

集群角色

Leader

• 处理所有读写请求,有一个Leader.
• 收到写请求,先记录事务日志,然后给Follower节点发送同步数据的请求。
• 只有一半以上的节点写事务日志成功,才会更新内存数据.

Follower

• 只能处理读请求，参与Leader选举.
• 收到的写请求会转发给Leader处理.
• Follower收到同步数据请求,也会记录事务日志，然后响应ACK.

Observer

• 只能处理读请求,收到的请求转发给Leader.
• 不参与选举，每增加一台Observer，可以分担读请求的压力，不影响服务端的性能.

集群选举

// 假设场景
现在启动zk集群，一共3个节点:myid = 1,myid = 2,myid = 3.
首先启动机器1和2，此时会进行leader选举
// 选举大致流程
1.第一轮投票都会先投自己一票
myid1 ->（1，0）
myid2 ->（2，0）
2.接着将自己的选票发送给对方
3.收到对方的选票和自己的选票进行pk 
(选举周期 > 事务id > 机器id)
myid1:(1，0),(2,0)
myid2:(2，0),(1,0)
4.第一轮pk结果
myid1:(2,0)
myid2: 2:(2,0)
5.进行第二轮投票，把第一轮胜出的票投出去
6.机器1和2都会投出（2，0）
7.最终机器2会有2票，超过半数，选为leader.
8.当后续myid = 3启动加入集群，已经存在leader，则自动变为follower

集群选举架构

// 涉及队列
// 1.sendqueue
这是本地应用层的发送队列，用于存放本地应用层产生的消息.
这些消息需要发送到集群中的其他服务器。这个队列中的消息会被WorkerSender处理并发送到集群中。
// 2.queueSendMap
这是传输层的待发送列表，存放的是需要发送到其他服务器的消息。
WorkerSender会从sendqueue中取出消息，然后将其放入queueSendMap中进行发送。
// 3.recvQueue
这是传输层的接收队列，存放其他服务器发来的消息。
当远端机器的queueSendMap中的消息发送到本机时，会被RecvWorker接收并放入recvQueue中。
// 4.recvqueue
这是本地应用层接收后的队列，存放recvQueue中的消息。
WorkerReceiver会从recvQueue中取出消息并将其放入recvqueue，供本地应用层进一步处理。

总体来说，这些队列和流程用于实现 ZooKeeper 集群中的 Leader 选举和消息传递机制。这是一个分布式系统中常见的模式，确保各个节点之间的通信和同步。

集群启动源码

可以通过下面zk集群启动的源码过程，加深zk集群的选举逻辑.