? ?
Zk server启动后会将最近最多500条事务保存在committedLog队列中，以便于leader->follower的增量同步。 同步策略说明
SNAP:leader将内存数据库快照序列化后发送给learner，learner全量替换本地的内存数据库
DIFF：以proposal+commit的方式，将committedLog的事务依次发给learner TRUNK:leader向learner发送(TRUNK+zxid)的消息，learner将日志删除到事务zxid位置
根据learner的lastZxid与committedLog的对应关系，将采用不同的同步策略： 1、 lastZxid小于minCommittedLog，采用SNAP全量同步策略
2、 lastZxid在minCommitedLog到maxCommittedLog之间，并包含在
committedlog之中，走DIFF增量同步策略
3、 lastZxid在minCommitedLog到maxCommittedLog之间，但不包含在
committedlog之中(发生此情况的场景为:leader发送proposal成功之前，虽然记录到了本地但是其它follower并没有记录，导致数据丢失，但是client一样会认为操作失败)，走TRUNK+DIFF同步策略.
4、 这种情况几乎不能发生，我能想到的是follower首先记录了该事务日志，但突然宕
机了，重启以后其它leader和follower依然还未执行记录该事务日志的操作。这种情况走TRUNK同步策略。
?
?
committedLog是提交以后的事务日志，那么等待ack以及正在被finalRequestProceesor处理的是什么时候发送的呢？ 答：Leader使用outstandingProposals等待ack的proposal，使用toBeApplied队列存放收到大多数ack但还没有被最终处理的proposal。在发送完数据库快照或者
committedlog后，紧接着会发送toBeApplied和outstandingProposals，然后将follower添加到forwarding列表，开始参与事务投票(proposal-ack-commit)的过程，以此来保证learner不会丢失任何事务消息
