如果有follower崩溃后恢复 ， 这时Raft追加条目的一致性检查生效 ， 保证follower能按顺序恢复崩溃后的缺失的日志 。 Raft的一致性检查：leader在每一个发往follower的追加条目RPC中 ， 会放入前一个日志条目的搜索引位置和任期号 ， 如果follower在它的日志中找不到前一个日志 ， 那么它就会拒绝此日志 ， leader收到follower的拒绝后 ， 会发送前一个日志条目 ， 从而逐渐向前定位到follower第一个缺失的日志 。

如果leader崩溃 ， 那么崩溃的leader可能已经复制了日志到部分follower但还没有提交 ， 而被选出的新leader又可能不具备这些日志（因为没有提交 ， 所以不违背下面的安全性规则） ， 这样就有部分follower中的日志和新leader的日志不相同 。 Raft在这种情况下 ， leader通过强制follower复制它的日志来解决不一致的问题 ， 这意味着follower中跟leader冲突的日志条目会被新leader的日志条目覆盖（因为没有提交 ， 所以不违背外部一致性） 。

3）安全性
最后 ， 我们讨论第三个子问题安全性（safety） 。
领导者选举和日志复制两个子问题实际上已经涵盖了共识算法的全程 ， 但目前所述的这两点还不能保证每一个状态机会按照相同的顺序执行相同的命令 。 （即怎样防范“后发先至”的可能性）
例如 ， 如果一个follower落后了leader若干条日志（但没有漏一整个任期） ， 那么下次选举中 ， 按照领导者选举里的规则 ， 它依旧有可能当选leader 。 它在当选新leader后就永远也无法补上之前缺失的那部分日志 ， 从而造成状态机之间的不一致 。
所以需要对领导者选举增加一个限制 ， 保证被选出来的leader一定包含了之前各任期的所有被提交的日志条目 。
Raft利用了一种近似于数学归纳的方法来保证这一点：follower只有判断candidate的日志条目“新”于自己 ， 才会投票给这个candidate；因为每条已提交的日志都至少同步给了过半节点 ， 所以只要一个candidate收集到了过半的选票 ， 那么它就一定具备了所有已提交的日志 。
三、总结
总结一下 ， Raft通过状态简化和三个子问题的分解 ， 规划出了一条清晰可行且易于理解的实现方法 ， 大大降低了分布式基础组件使用共识算法的难度 。
Raft论文中还对43个大学生做了个实验 ， 结果显示 ， 其中有33个人学习Raft的成绩好于学习Paxos的成绩 。
实用性角度看 ， 从Raft算法发布之后 ， 也就是2014年之后 ， 在Paxos和Raft之间选择Raft的软件就越来越多 。 开发者们表示：从前我没得选 ， 现在我只想选Raft 。
可见 ， 算法的易理解性还是很重要滴 ， 再好的东西 ， 也要别人能理解并使用啊！
更多干货
四期精选“数据库”主题直播回看：
数据库前沿技术实践与应用趋势探讨：http://z-mz.cn/4CjCp
金融业数据库转型与国产化改造：http://z-mz.cn/3QOjX
【最清晰易懂的Raft算法讲解】主流关系型分布式数据库选型与设计实战：http://z-mz.cn/3GOHl
金融级数据库架构设计与运维实践：http://z-mz.cn/1vTkl
关注公众号dbaplus社群回复【220318】 ， 可获取配套PPT哦~
最新一期直播【云原生运维转型的多维度探索】将于4月9日开播 ， 通过下方链接进入直播间 ， 点击开播提醒 ， 精彩内容不错过！
http://z-mz.cn/51yK9
dbaplus社群欢迎广大技术人员投稿 ， 投稿邮箱：editor@dbaplus.cn
关注公众号【dbaplus社群】 ， 获取更多原创技术文章和精选工具下载