有一些文章, 包括 Raft 协议的论文, 已经从反例的角度解释了为什么不允许 Leader 直接 commit 前任的日志, 而是必须追加本任期的一条日志, 以达到隐式地 commit 前任的日志. 我想从 Raft 的几项原则的角度, 在逻辑上解释这个问题.

Raft 策略1: 节点的日志一旦 commit 便不可撤销

某个节点的一条日志, 一旦 commit 它, 那么就会对状态机造成不可逆的改变. 也许某些状态机有回滚功能, 但在 Raft 的架构中, 假设状态机不可回滚. 因此, 日志一旦 commit, 便不可撤销.

注意, 这里用的是"策略"一词, 表明这是人为规定的规则, 不是客观存在的定理.

Raft 策略2: 节点的日志在 commit 之前可被撤销

某个节点的一条日志, 如果还没有 commit, 那么未来有可能被其它的日志(相同 index 但不同 term)替换掉. 见后面分析什么场景下会出现日志被撤销(替换)的情况.

Raft 目标: 所有的节点最终应该 commit 相同的日志

这个目标是共识算法的基础特性, 不然就不叫共识算法.

Raft 常识: 不同的节点独立 commit

虽然 Leader commit 的一条日志, 但在上帝视角看, 其它节点还没有 commit, 也许过一天才 commit 也有可能.

问题的出现(4任 Leader)

第1任和第2任 Leader 针对同一个 index, 各自产生了两条不同 term 的日志, 均没有形成 quorum. 这时, 第3任 Leader 可以继承两者之中任意一个, 可以继承1, 也可以继承2. 注意: 任期数字之间不代表继承关系.

第3任会继承前任(假设继承第1任)的日志, 并复制到其它节点, 导致第2任的日志被替换掉了. 接着产生了新的第4任(继承第2任), 那么它又会导致第1任的日志被替换掉.

那么, 为什么 commit 自己任期的日志, 就能确保日志不会被撤销呢? 原因有两条:

1. Leader 永远不会主动撤销自己任期和前任的日志

2. 新 Leader 必须包含 quorum 中最新的日志

Leader 如果能确认自己任期的日志已经复制给了 quorum, 就能确保这条日志一定会被新 Leader 以及未来的所有 Leader 继承.

但是, 只有自己任期的日志才能下这个结论, 前任的日志即使已经复制给了 quorum, 也有可能被撤销.

建议继续学习：

1. server日志的路径分析    (阅读：10115)
2. AWStats简介：Apache/Windows IIS的日志分析工具的下载，安装，配置样例和使用（含6.9中文定义补丁）    (阅读：8862)
3. 利用脚本分析日志并利用snmp自定义OID，再通过cacti画图    (阅读：8689)
4. tomcat catalina.out日志切割每天生成一个文件    (阅读：8090)
5. 分布式日志系统scribe使用手记    (阅读：8045)
6. AWStats是一个基于Perl的WEB日志分析工具。    (阅读：6111)
7. 使用nginx记日志    (阅读：5082)
8. 大于2GB的Listener.log和运行超过198天的主机上的Oracle实例    (阅读：4877)
9. 在 shell 脚本里打日志    (阅读：4786)
10. Sentry: 错误日志集中管理    (阅读：4359)