第一种情况这些数据只有老Leader自己知道当老Leader重启后需要与新Leader同步并把这些数据从本地删除以维持状态一致。
第二种情况新Leader应该能通过一个多数派获得老Leader提交的最新数据
老Leader重启后可能还会认为自己是Leader可能会继续发送未完成的请求从而因为两个Leader同时存在导致算法过程失败解决办法是把Leader信息加入每条消息的id中Zookeeper中称为zxidzxid为一64位数字高32位为leader信息又称为epoch每次leader转换时递增低32位为消息编号Leader转换时应该从0重新开始编号。通过zxidFollower能很容易发现请求是否来自老Leader从而拒绝老Leader的请求。
因为在老Leader中存在着数据删除情况1因此Zookeeper的数据存储要支持补偿操作这也就需要像数据库一样记录log。 3. Zab与Paxos
Zab的作者认为Zab与paxos并不相同只所以没有采用Paxos是因为Paxos保证不了全序顺序
Because multiple leaders can
propose a value for a given instance two problems arise.
First, proposals can conflict. Paxos uses ballots to detect and resolve conflicting proposals.
Second, it is not enough to know that a given instance number has been committed, processes must also be able to figure out which value has been committed.
Paxos算法的确是不关系请求之间的逻辑顺序而只考虑数据之间的全序但很少有人直接使用paxos算法都会经过一定的简化、优化。
一般Paxos都会有几种简化形式其中之一便是在存在Leader的情况下可以简化为1个阶段Phase2。仅有一个阶段的场景需要有一个健壮的Leader因此工作重点就变为Leader选举在考虑到Learner的过程还需要一个”学习“的阶段通过这种方式Paxos可简化为两个阶段