? ?
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不会丢失任何事务消息
相关推荐: