温州企业网站制作,网站主要栏目,做一年的网站维护价格,来个网站奖励自己Zookeeper选举Leader源码剖析
leader选举流程
参数说明 myid: 节点的唯一标识#xff0c;手动设置zxid: 当前节点中最大(新)的事务idepoch-logic-clock: 同一轮投票过程中的逻辑时钟值相同#xff0c;每投完一次值会增加 leader选举流程 默认投票给自己#xff0c;优先选择…Zookeeper选举Leader源码剖析
leader选举流程
参数说明 myid: 节点的唯一标识手动设置zxid: 当前节点中最大(新)的事务idepoch-logic-clock: 同一轮投票过程中的逻辑时钟值相同每投完一次值会增加 leader选举流程 默认投票给自己优先选择zxid大的为leader因为zxid大的节点数据是最新的(理论上事务id越大说明数据量越多也就意味着比较新)如果zxid一致那么会选择myid大的为leader当节点选票过半则选举成功
leader选举核心步骤 源码大致流程 初始化netty通信客户端发送命令立刻监听到 初始化内存数据库对象、初始化服务连接工厂等一些信息 启动服务节点 加载文件数据到内存启动netty服务初始化集群选举leader启动一个线程进行选举监听监听到选票将选票丢到recvQueue队列中 启动接收选票线程、发送选票线程进行监听都去队列中接受和发送选票 启动QuorumPeer线程执行run方法根据节点状态判断 leading: socket监听follower节点初始化LeaerZookeeperServer数据同步数据到从节点定时ping到follower节点请求保持长连接 follower: 与leader建立发送socket连接注册自己到leader、同步leader数据、自旋接收leader同步数据如果leader宕了在finally中将自己的状态改为looking进入下一轮自旋选举looking: 节点启动后的默认状态选举周期1初始化选票默认选自己发送选票到sendQueue队列同时还会不断地从recvQueue队列拿选票进行选举 问题: ZK的选举机制为什么存在大量自旋如同步节点数据、选举流程如果长时间运行会不会导致CPU资源损耗过大 对于长时间自旋毋庸置疑肯定会导致CPU资源紧张但是想达到动态监听数据变化就得牺牲一定的CPU性能并且这样也能保证数据的强一致性也能保证节点选举的实时性倘若想要优化ZK可以引入Redis/MQ基于发布/订阅模式进行处理但是这样会造成引入三方中间件导致复杂度提升
