Raft 为什么不能直接 commit 前任的日志?
有一些文章, 包括 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 自己任期的日志, 就能确保日志不会被撤销呢? 原因有两条:
Leader 永远不会主动撤销自己任期和前任的日志
新 Leader 必须包含 quorum 中最新的日志
Leader 如果能确认自己任期的日志已经复制给了 quorum, 就能确保这条日志一定会被新 Leader 以及未来的所有 Leader 继承.
但是, 只有自己任期的日志才能下这个结论, 前任的日志即使已经复制给了 quorum, 也有可能被撤销.
建议继续学习:
- server日志的路径分析 (阅读:10203)
- AWStats简介:Apache/Windows IIS的日志分析工具的下载,安装,配置样例和使用(含6.9中文定义补丁) (阅读:8953)
- 利用脚本分析日志并利用snmp自定义OID,再通过cacti画图 (阅读:8749)
- tomcat catalina.out日志切割每天生成一个文件 (阅读:8135)
- 分布式日志系统scribe使用手记 (阅读:8097)
- AWStats是一个基于Perl的WEB日志分析工具。 (阅读:6162)
- 使用nginx记日志 (阅读:5175)
- 大于2GB的Listener.log和运行超过198天的主机上的Oracle实例 (阅读:4971)
- 在 shell 脚本里打日志 (阅读:4838)
- Sentry: 错误日志集中管理 (阅读:4415)
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:ideawu 来源: idea's blog
- 标签: commit raft 日志
- 发布时间:2021-05-26 22:46:03
- [70] Twitter/微博客的学习摘要
- [65] find命令的一点注意事项
- [64] 如何拿下简短的域名
- [64] IOS安全–浅谈关于IOS加固的几种方法
- [63] android 开发入门
- [62] 流程管理与用户研究
- [62] Go Reflect 性能
- [60] Oracle MTS模式下 进程地址与会话信
- [59] 读书笔记-壹百度:百度十年千倍的29条法则
- [59] 图书馆的世界纪录