共 2 篇相关文章
共识算法旨在解决分布式系统在部分节点故障或网络异常时，如何让存活节点就系统状态达成一致的根本问题。它不仅是实现状态机复制的理论基础，也是 Leader 选举、原子广播和集群配置变更等核心功能的驱动力。不同于两阶段提交协议的阻塞特性，共识算法追求的是在容错前提下达成一致，即使少数节点失效也能保证系统持续推进。 其核心目标是在不可靠的异步网络中，使一组进程就某个提议值达成唯一且不可逆的协定。这一机制广泛应用于确保主从复制的正确性、维护分布式数据库的副本一致、实现分布式事务的原子性以及决定事件的全局顺序等场景。 算法的复杂性主要源于节点崩溃、网络延迟或分区、拜占庭故障等挑战。从概念上必须区分“共识”与“一致性”：一致性描述数据副本的状态或外部视图的一致，而共识是达成该状态所采用的一种内部协调协议，是实现强一致性的重要技术手段。
这篇讲的是 Raft 共识协议中一个容易被忽略但至关重要的设计细节：为什么 Leader 不能直接提交前任任期的日志，而必须通过提交本任期的新日志来“隐式”提交。 作者从 Raft 的几项基本原则出发，进行逻辑推演。他指出，一旦日志被 commit，对状态机的影响就不可撤销；而未 commit 的日志则可能被同一 index 不同 term 的新日志替换。核心目标是让所有节点最终提交相同的日志。 问题在多个 Leader 交替时浮现。例如，前两任 Leader 针对同一 index 产生的日志均未形成多数派，第三任 Leader 可能继承其中任一个，这就会导致另一条日志被替换。文章强调，只有 commit 自己任期的日志才能确保它“永不丢失”。这是因为现任 Leader 永远不会撤销自己任期的日志，且新当选的 Leader 一定包含上一个任期多数派中的最新日志。因此，确认本任期日志已复制到多数节点，就能保证它被所有后续 Leader 继承。 这个推理解释了 Raft 论文中反例背后的深层原理，揭示了“隐式提交”机制是如何在日志可能被覆盖的复杂场景下，依然坚定地维护日志一致性的。
