Zookeeper(六)-选主-概念分析
zk通过Multi-Paxos思想实现分布式一致性，Multi-Paxos为了解决Paxos需要2轮RPC通讯(准备阶段和接受阶段)往返消息多、耗性能、延迟大的问题引入了Leader-Follower-Learner模式；考虑到高可用性，有Leader就会涉及选举Leader的问题，本节就来分析下zk是如何实现选主的；
以三个节点同时启动为例：
以3个节点中Server1作为Follower重启为例：
以4个节点中Server4作为Leader宕机为例：
Leader ：一个zk集群同一时刻只有一个Leader，所有写操作必须通过Leader完成，然后再广播给其他服务器；
Follower ：一个zk集群同一时刻有多个Follower。Follower可以直接处理读请求，但是写请求需要转发给Leader处理，同时负责在Leader处理写请求时对请求进行投票；
Observer ：功能跟Follower类似，但是没有投票权；
Looking ：寻找Leader状态，处于该状态的服务器会发起选主；
Following ：跟随者状态，表明当前服务器是Follower；
Leading ：领导者状态，表明当前服务器是Leader;
Observing ：观察者状态，表明当前服务器是Observer;
Listener.run 监听2888端口，阻塞在ServerSocket.accept，等待其他服务器请求创建连接；
RecvWorker.run 阻塞在DataInputStream.read，获取对应服务器发送的投票信息；
SendWorker.run 阻塞在ArrayBlockingQueue.poll，获取待发送消息，发送给对应服务器；
WorkerReceiver.run 阻塞在recvqueue.poll，获取RecvWorker.run中接收的投票消息Notification；
WorkerSender.run 阻塞在sendqueue.poll，获取待发送ToSend到SendWorker.run进行处理；
QuorumPeer.run 集群模式启动过程中选举结束后，根据当前服务器状态进行之后的异步流程处理；
LinkedBlockingQueue<ToSend> sendqueue FastLeaderElection中的请求发送队列，存放的是ToSend；
LinkedBlockingQueue<Notification> recvqueue FastLeaderElection中的请求接受队列，存放的是Notification；
ConcurrentHashMap<Long, SendWorker> senderWorkerMap sid -> 当前服务器到该sid的SendWorker；每个服务器会跟比自己sid小的服务器创建一个SendWorker用于投票选主时发送投票信息；
ConcurrentHashMap<Long, ArrayBlockingQueue<ByteBuffer>> queueSendMap sid -> 当前服务器需要发送到该sid的投票消息的队列；WorkerSender.run中会根据不同sid把对用的选票信息放入对应的ArrayBlockingQueue中；
ConcurrentHashMap<Long, ByteBuffer> lastMessageSent sid->最后一次发送到该sid的投票信息；
ArrayBlockingQueue<Message> recvQueue WorkerReceiver.run中接收到的投票信息，解析字节流转成Message放到recvQueue中；
zk选主涉及6个线程、多个集合，过程比较饶，必须要先把选主的流程和各个线程、集合的作用等搞清楚，不然理解起来比较难。下一节通过源码来具体分析选主的实现；
------ over ------
迈杰
2024-11-30 广告
