zk源码阅读43：集群版启动小结(二):选举完leader到le

前言

前面几节中，主要讲了如下内容

38节讲了集群版服务器角色，与消息类型
39节讲了Leader和Follower服务器启动期交互概述
40-42节讲了Learner，LearnerHandler，Leader的源码

小结

这里小结一下，可以结合39节进行整理
主要讲解了如下步骤

38-42节在集群版启动的位置

Leader和Learner的同步流程如下

Leader和Learner的同步流程

思考

什么时候会出现回滚

learner有leader没有的zxid记录

原理涉及到请求处理链，可以看完后续部分，再来看这里

场景:原leader处理提议，
ProposalRequestProcessor#processRequest

leader处理提议

这里有两个部分:
1.SyncRequestProcessor处理
2.发出提议Leader#propose

1.SyncRequestProcessor处理请求
SyncRequestProcessor#processRequest
异步run方法会尽快的写入日志，调用
zks.getZKDatabase().append(si)
底层是
FileTxnLog#append

2.发出提议Leader#propose
异步等待learner 回复ACK处理Leader#processAck

那么会出现proposal没有发出去(网络原因),但是事务日志已经加上了，然后leader挂掉了
此时的learner都没有这一条事务日志

之后重新选举了新leader之后，老的leader以learner的形式来同步，就会发送一条当前leader没有的zxid记录
以此引发TRUNC

refer

http://ningg.top/zookeeper-lesson-9-zookeeper-data-and-storage/ 同步的图
http://damacheng009.iteye.com/blog/2086046 (一开始没有理解为什么会出现leader的zxid比learner的低，看着一篇再看源码就懂了)