Zab系列1 核心概念

Zab系列博客

Raft Vs Zab
https://www.jianshu.com/p/24307e7ca9da
Zab系列1 核心概念
https://www.jianshu.com/p/76e5dba31ea4
Zab系列2 角色和存储
https://www.jianshu.com/p/d80f9250ffd1
Zab系列3 选举
https://www.jianshu.com/p/0d2390c242f6
Zab系列4 zookeeper特性
https://www.jianshu.com/p/08b62ca1fe4e
Zab系列5 选举恢复（源码分析）
https://www.jianshu.com/p/b6acd99921b7
Zab系列6 zk单机版工作原理
https://www.jianshu.com/p/ed45982b18b4
Zab系列7 集群工作原理Leader篇
https://www.jianshu.com/p/59240c36ba1b
Zab系列8 集群工作原理Follower篇
https://www.jianshu.com/p/8d7c7f1b2838

名词解释

• electionEpoch：每执行一次leader选举，electionEpoch就会自增，用来标记leader选举的轮次。（相当于Raft系统中的term)

• peerEpoch：每次leader选举完成之后，会把leader最终的electionEpoch赋值到peerEpoch。其实和electionEpoch是2个不同的值，比如在选举期间，该Node的peerEpoch不会变，而且lastCommitZxid里面的高32位也不会变，但是electionEpoch会自增1

• zxid：事务请求的唯一标记，由leader服务器负责进行分配。由2部分构成，高32位是上述的peerEpoch，低32位是请求的计数，每次都从0开始。所以由zxid我们就可以知道该请求是哪个轮次的，并且是该轮次的第几个请求。
  （zxid和Raft系统中的 logTerm、logIndex，不完全一样，zxid的peerEpoch和term是一个概念，但是低32位不是logIndex，低32位是从0开始递增的一个计数器。)

• lastProcessedZxid：最后一次commit的事务请求的zxid
  （选举的时候，谁的zxid大，谁就更有机会成为leader）
  （同步数据的时候，leader给follower同步数据的时候，可以根据zxid来确定要补上哪些数据）

• committedLog：LinkedList，ZooKeeper会保存最近一段时间内执行的事务请求议案，个数限制默认为500个议案。上述committedLog就是用来保存议案的列表，上述maxCommittedLog表示最大议案的zxid，minCommittedLog表示committedLog中最小议案的zxid。

• outstandingProposals（待confirm）：ConcurrentMapLeader拥有的属性，每当提出一个议案，都会将该议案存放至outstandingProposals，一旦议案被过半认同了，就要提交该议案，则从outstandingProposals中删除该议案

• toBeApplied（待apply）：ConcurrentLinkedQueue ，Leader拥有的属性，每当准备提交一个议案，就会将该议案存放至该列表中，一旦议案应用到ZooKeeper的内存树中了，然后就可以将该议案从toBeApplied中删除

Notification

数据结构

• sid 表示这个消息是谁发过来了，也就是投票人
• leader 表示投票获得者的 sid（myid)
• state：following（表示sid投票给leader，但是sid仍然没有产生leader）、leading（表示 sid 认为 leader机器 满足了leading条件）

    int version;
    //Proposed leader
    long leader;
    long zxid;
    long electionEpoch;
    //current state of sender
    QuorumPeer.ServerState state;
    //Address of sender
    long sid;
    QuorumVerifier qv;
    long peerEpoch;

• 可能是某个Node更新了自己的投票结果，广播给别人的Notification
• 可能是某个Node广播自己已经找到了新leader，那么state=leading

• 最后都会被更新进recvset里面：

recvset.put(n.sid, new Vote(n.leader, n.zxid, n.electionEpoch, n.peerEpoch));

recvset

HashMap 用于收集LOOKING、FOLLOWING、LEADING状态下的server的投票
注意了，不仅仅是Looking状态下的投票，还有FOLLOWING、LEADING状态下的server的投票

Map recvset = new HashMap();
recvset.put(n.sid, new Vote(n.leader, n.zxid, n.electionEpoch, n.peerEpoch));

• key代表是 Notification.Sender.sid，标志着这个消息是哪个节点的最新投票数据

• recvset 归档set，key是vote发起方的ID，value是该发起方的最新的Vote值，因为所有Node的Vote值都是越来越新，节点只会投票给比自己当下最新的数据还新的节点投赞成票

• recvset用于记录当前服务器在本轮次的Leader选举中收到的所有外部投票（按照服务队的SID区别，如{(1, vote1), (2, vote2)...}）

• recvset 当收到投票广播消息时，如果自己的任期小于约票的任期，就会清空recvset，因为老的recvset已经过期了，现在要PK新任期的选举投票了

outofelection

HashMap，用于收集FOLLOWING、LEADING状态下的server的投票（能够收集到这种状态下的投票，说明leader选举已经完成）
比如A节点统计投票，发现B节点在A节点上的投票满足半数，那么A进入follower状态，广播一个消息 sid=A，state=leading，leader=leaderID
比如A节点统计投票，发现A节点在A节点上的投票满足半数，那么A进入leading状态，广播一个消息 sid=A，state=leading，leader=sid
因为节点的投票结束消息，理论上不会重复投票，一个节点确认了leader之后，就会进入following状态。采用hashmap的数据结构为了实现快速的，根据sid找到投票获得者信息的方式，而不叫outofelectionSet，因为不需要过滤。

参考

ZooKeeper的一致性算法赏析
https://my.oschina.net/pingpangkuangmo/blog/778927?spm=a2c4e.11153940.blogcont62901.11.12c62ee5vwzG6o

辅助
https://www.jianshu.com/p/357ca7c3b2af

zookeeper官网说明
https://zookeeper.apache.org/doc/r3.5.4-beta/zookeeperOver.html

zookeeper官网说明中文翻译版
https://blog.csdn.net/lisuo1234/article/details/55826380