一页技术：Zookeeper的顺序一致性

朱雀 2023-02-11 10:25 51阅读 0赞

._ 用途
    . ._ 注册中心
    . ._ 分布式锁
    ._ 顺序一致性
    . ._ ZAB协议
    . . ._ 原理
    . . . ._ 两阶段提交
    . . . ._ 最终一致性
    . . ._ 组件
    . . . ._ leader
    . . . ._ follow
    . . ._ 过程
    . . . . 第一阶段
    . . . . 每次数据写入过程作为事件广播给所有follow节点
    . . . . 可以写入的节点返回确认信息ack
    . . . . 第二阶段
    . . . . leader收到一半以上的ack信息后，确认写入可以生效，向所有节点广播commit将提案生效。
    . . ._ 事务顺序
    . . . ._ 事务id：zxid
    . . . . 通过比较zxid和机器id选出新的主节点，zxid由主节点生成，有新写入事件时，leader生成新zxid并随提案一起广播。
    . . . . 每个节点本地都保存了最近一次事务的zxid，zxid是递增的，所以谁的zxid最大，谁的数据是最新的。
    . . . ._ zxid的生成规则
    . . . . ._ 一部分是任期，完成本次选举后，直到下次选举前，由同一leader负责协调写入。
    . . . . ._ 另一部部分是事务计数器，单调递增，每生效一次写入，计数器加一。
    . . . . ._ zxid的第32位是计数器，所以同一任期内zxid是连续的。每个节点保存着最新生效的zxid，通过对比新提案的zxid与自身最新的zxid是否相差1，保证事务是按照顺序严格生效的。
    . . . ._ 高并发情况
    . . . . . leader收到半数以上ack后，会将天生效并广播给所有follow节点，leader为了保证事务按zxid生效，使用了一个currenthashmap记录所有未提交的提案，命名为outsidingProposals，key为zxid，value为提案信息，对outsidingProposals的访问逻辑如下：
    . . . . . 1.每发起一个提案，会将提案的zxif和内容放到outsidingProposals中，作为待提交的提案，
    . . . . . 2.收到follow的ack信息后，根据ack中的zxid从outsidingProposal中找到对应的提案，对ack计数。
    . . . . . 3.执行commit尝试将提案提交，判断流程为：先判断当前的zxid之前是否还有未提交提案，如果有，当前提案暂时不能提交，再判断提案是否收到半数以上ack，如果达到半数，则可以提交，将当前zxid从outsidingProposal中清除并向follows广播提交当前提案。
    . . . . ._ leader如何判断当前提案前是否还有未提交提案，由于事务是按照顺序提交的，所以只需判断zxid前一个zxid是否存在即可。
    ._ 选举
    . ._ Fast算法
    . . ._ 四种状态
    . . . ._ LOOKING
    . . . . ._ 寻找Leader状态。当服务器处于该状态时，它会认为当前集群中没有Leader，因此需要进入Leader选举状态
    . . . ._ LEADING
    . . . . ._ 跟随者状态。表明当前服务器角色是Follower
    . . . ._ FOLLOWING
    . . . . ._ 领导者状态。表明当前服务器角色是Leader
    . . . ._ OBSERVING
    . . . . ._ 观察者状态。表明当前服务器角色是Observer
    . . ._ 选举过程
    . . . ._ 启动时期选举
    . . . . ._ 1.每个Server发出一个投票
    . . . . . ._ 由于是初始情况，Server1和Server2都会将自己作为Leader服务器来进行投票，每次投票会包含所推举的服务器的myid和ZXID，使用(myid, ZXID)来表示，此时Server1的投票为(1, 0)，Server2的投票为(2, 0)，然后各自将这个投票发给集群中其他机器。
    . . . . ._ 2.接受来自各个服务器的投票
    . . . . . ._ 集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票、是否来自LOOKING状态的服务器
    . . . . ._ 处理投票
    . . . . . ._ 针对每一个投票，服务器都需要将别人的投票和自己的投票进行PK
    . . . . . . ._ 优先检查ZXID。ZXID比较大的服务器优先作为Leader。
    . . . . . . ._ 如果ZXID相同，那么就比较myid。myid较大的服务器作为Leader服务器
    . . . . ._ 3.统计投票
    . . . . . ._ 每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，对于Server1、Server2而言，都统计出集群中已经有两台机器接受了(2, 0)的投票信息，此时便认为已经选出了Leader
    . . . . ._ 5.改变服务器状态
    . . . . . ._ 一旦确定了Leader，每个服务器就会更新自己的状态，如果是Follower，那么就变更为FOLLOWING，如果是Leader，就变更为LEADING
    . . . ._ 运行时期选举
    . . . . ._ 
    . . . . ._ 1.变更状态
    . . . . . ._ Leader挂后，余下的非Observer服务器都会将自己的服务器状态变更为LOOKING，然后开始进入Leader选举过程
    . . . . ._ 2.每个Server会发出一个投票
    . . . . . ._ 在运行期间，每个服务器上的ZXID可能不同，此时假定Server1的ZXID为123，Server3的ZXID为122；在第一轮投票中，Server1和Server3都会投自己，产生投票(1, 123)，(3, 122)，然后各自将投票发送给集群中所有机器
    . . . . ._ 3.接收来自各个服务器的投票
    . . . . . ._ 与启动时选举过程相同
    . . . . ._ 4.统计投票
    . . . . . ._ 与启动时选举过程相同
    . . . . ._ 5.改变服务器的状态
    . . . . . ._ 与启动时选举过程相同
    . . ._ 比较逻辑
    . . . ._ 1.比较epoch
    . . . . ._ 当前的逻辑时钟（投票轮次）与被选举的server的逻辑时钟比较。大者胜出。如相同则进行下一步比较。
    . . . ._ 2.比较zxid
    . . . . ._ 当前server的事务id与被选举的server的事务id比较，大者胜出。如相同则进行下一步比较。
    . . . ._ 3.比较sid
    . . . . ._ 当前serverid与选举serverid比较，大者胜出
    . . ._ 选举数据结构
    . . . ._ id
    . . . . ._ 被推举的Leader的SID
    . . . ._ zxid
    . . . . ._ 被推举的Leader事务ID
    . . . ._ electionEpoch
    . . . . ._ 逻辑时钟，用来判断多个投票是否在同一轮选举周期中，该值在服务端是一个自增序列，每次进入新一轮的投票后，都会对该值进行加1操作
    . . . ._ peerEpoch
    . . . . ._ 被推举的Leader的epoch
    . . . ._ state
    . . . . ._ 当前服务器的状态
    . . ._ 核心
    . . . ._

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5nYmI4Njg2_size_16_color_FFFFFF_t_70][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5nYmI4Njg2_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200523105313877.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5nYmI4Njg2,size_16,color_FFFFFF,t_70