• https://zhuanlan.zhihu.com/p/27335748
• **https://jimmy2angel.github.io/2019/01/12/Zookeeper-ZAB%E5%8D%8F%E8%AE%AE/ zk如何保证以下两点：
  • 已经被旧 Leader 提交 的 proposal 不能丢
  • 保证丢弃那些只在旧 Leader 上 提出 的 proposal
• ZAB协议的四阶段图解
• https://blog.csdn.net/u013679744/article/details/79240249
• https://my.oschina.net/pingpangkuangmo/blog/778927 各种变量名的解析

选举时比较的zxid来自QuorumPeer::getLastProcessedZxid()->ZKDatabase::getDataTreeLastProcessedZxid->return dataTree.lastProcessedZxid;，应该是最后事务的zxid(不一定要commit)

zab论文

The main postcondition that Fast Leader Election attempts to guarantee for the subsequent Recovery Phase is that the leader will have in its history all committed transactions. This is supported by the assumption that the peer with the most recent proposed
transaction must have also the most recent committed transaction. For performing the
synchronization, Recovery Phase assumes this postcondition holds. If, however, the postcondition does not hold, a follower might have a committed transaction that the leader does not have. In that situation, the replicas would be inconsistent, and Recovery Phase would not be able to bring the ensemble to a consistent state, since the synchronization direction is strictly from leader to followers.

In order to do so, committed transactions in any replica must be committed
in all other replicas, in the same order. Furthermore, proposed transactions that should
not be committed anymore must be abandoned so that no peer commits them.

zookeeper是如何避免raft中Figure 8的overwrite问题的?

不知道

Leader::lead行为

https://juejin.im/entry/5acb7afd6fb9a028c676043c
同步部分
LearnerHandler::syncFollower负责同步部分. queueCommittedProposals方法:

// Since this is already a committed proposal, we need to follow
// it by a commit packet
queuePacket(propose.packet);
queueOpPacket(Leader.COMMIT, packetZxid);
queuedZxid = packetZxid;

每个committed事务都会紧跟一个COMMIT操作.(如果这个commit操作丢失了怎么办?还会在之后被提交吗?)

同步完成时发送UPTODATE, 调用了takeSnapshot, 生成快照.
如果在RAFT中,应当一次性将所有事务commit, 但是利用生成快照的方式?

我只看到同步commit事务的操作,没看到非commit事务是在哪里同步的