Zookeeper崩溃恢复过程(Leader选举)

最新推荐文章于 2025-06-11 11:20:09 发布

weixin_30268071

最新推荐文章于 2025-06-11 11:20:09 发布

阅读量845

点赞数

CC 4.0 BY-SA版权

文章标签：大数据数据结构与算法

原文链接：http://www.cnblogs.com/Desneo/p/7608441.html

本文详细介绍了ZooKeeper中Leader选举的过程，包括崩溃恢复机制、服务器状态、投票数据结构及选举流程等核心内容。重点阐述了ZAB协议如何确保数据一致性，以及通过QuorumCnxManager组件实现的选举过程。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

1. 崩溃恢复

    a). leader选择过程可以保证新leader是ZXID最大的节点
    b). ZAB协议确保丢弃那些只在leader上被提出的事务，场景 leader发出PROPOSAL收到ACK，但是发出COMMIT前产生崩溃，则新的群组会丢弃这条消息

2. Leader选举过程

2.1 服务器状态

LOOKING 系统刚启动或Leader崩溃后选举状态，认为当前集群中没有leader，因此要进入选举流程
FOLLOWING 跟随者状态，角色是Follower
LEADING 领导者状态，leader
OBSERVING 观察者状态(只支持查询，不参与选举)，Observer

2.2 投票数据结构-Vote

id      被推举的Leader的SID值
zxid    被推举的Leader的事务ID
electionEpoch   逻辑时钟，用来判断多个投票是否在同一轮选举周期中。该值在服务端是一个自增序列。
                每次进入新一轮的投票后，都会对该值进行加1操作。
peerEpoch       被推举的Leader的epoch值
state           当前服务器的状态

2.3 QuorumCnxManager-Server Socket负责选举

a). 每台服务器启动时都会启动一个QuorumCnxManager--Server Socket,负责服务器之间的Leader选举过程。
b). 内部维护几个队列，每个队列又是按SID分组的队列集合
    recvQueue   选票接收队列
    queueSendMap    待发送的消息，内部按SID为每台机器分配了一个单独队列，保证互补影响
    sendWorkerMap   负责消息发送，也按SID进行了分组
    lastMesageSent  最近发送的消息，按SID进行分组
c). 建立连接, 集群中机器需要进行两两连接，规则"只允许SID大的机器主动和其它机器进行连接，否则断开连接"来防止重复连接

d). 当服务器检测到当前服务器状态变成LOOKING时，就会触发leader选举
    0).如果已存在leader，则发送选票后会被告知leader的信息，直接连接即可，不需要进行后续步骤

    1). 自增选举轮次，在FastLeaderElection实现中有一个logicalclock属性，用来标识当前Leader选举轮次，ZK规定所有投票必须
        在同一个轮次，server开始新一轮投票前会进行自增操作。

    2). 初始化选票(第一次先投票给自己)，参照前面的Vote结构
    3). 发送初始化选票

    4). zk从reeviveQueue接收外部投票
        如果zk发现自己无法获得任何投票，则马上检查是否与其他zk保持了有效连接，无则建立，并再次发送自己当前的内部投票

    5). 判断选举轮次(接收到的外部投票)
        I). 外部投票轮次大于内部投票    立即更新自己的选举轮次(logicalclock),并清空已收到的所有投票，然后使用初始化的投票来PK(第6步)
                是否变更内部投票，最终再将内部投票发送出去。
        II). 外部投票的轮次小于内部投票  zk直接忽略该投票，不做任何处理，返回步骤4
        III). 内外部轮次一致   开始选票PK
    
    6). 选票PK    比较顺序从先到后依次是  轮次 > ZXID > SID ,3种比较都是 "外部大于内部，则进行投票变更”
    
    7). 投票变更    用外部投票的信息覆盖内部投票，变更完成后，再次将这个投票信息发送出去
    
    8). 选票归档    无论是否进行了选票变更，都会将刚刚收到的那份外部投票放入选票集合"recvset"中，recvset内部按SID存在本轮次收到的所有外部投票
    9). 统计投票    完成选票归档以后，就开始统计投票。如果确定已经有超过半数的服务器认可了该内部投票，则终止投票。
            否则返回步骤4.
    
    10). 如果可以终止投票(再等待200ms来确定是否有更优的投票)，则更新服务器状态     
            首先判断投票选出的Leader是否是自己，然后更具情况更新自己状态为LEADING/FOLLOWING/OBSERVING
    
    11). 选出Leader后，所有learner向leader发送LEARNERINFO消息，等待超过半数的learner连接完成后(取他们最大的epoch当做leader的epoch值)

    12). leader向learner发送LEADERINFO消息，learner从中解析出epoch和ZXID,然后向Leader反馈一个ACKEPOCH
    
    13). Leader接收到该Learner的ACK后就开始与其进入”数据同步“环节

转载于:https://www.cnblogs.com/Desneo/p/7608441.html