换句话说，可以理解为共识算法就是用来确保每个节点上的日志顺序都是一致的。 <!-- more --> [拜占庭将军问题](拜占庭将军问题) 两个反例： 1. 桃花源记中的不知有汉 无论魏晋 2. 有一名日本军官，二战结束后仍在菲律宾孤岛负隅顽抗30年 [共识算法](1%20一切皆项目/搁置中/Q2：做CS的经典lab%201/Q2：做CS的经典lab/共识算法.md) 允许一组节点像一个整体一样一起工作，即使其中一些节点出现故障也能够继续工作下去，其正确性主要源于复制状态机的性质： > 任何初始状态一样的状态机，如果执行的命令序列一样，则最终达到的状态也一样。如果将此特性应用在多参与者进行协商共识上，可以理解为系统中存在多个具有完全相同的状态机（参与者），这些状态机能最终保持一致的关键就是起始状态完全一致和执行命令序列完全一致。 众所周知，[Paxos](Paxos) 是一个非常划时代的共识算法。在 Raft 出现之前的 10 年里，Paxos 几乎统治着共识算法这一领域：因为绝大多数共识算法的实现都是基于 Paxos 或者受其影响，同时 Paxos 也成为了教学领域里讲解共识问题时的示例。但是不幸的是，尽管有很多工作都在尝试降低 Paxos 的复杂性，但是它依然十分难以理解。并且，Paxos 自身的算法结构需要进行大幅的修改才能够应用到实际的系统中。这些都导致了工业界和学术界都对 Paxos 算法感到十分头疼。比如 Google Chubby 的论文就提到，因为 Paxos 的描述和现实差距太大，所以最终人们总会实现一套未经证实的类 Paxos 协议。 基于以上背景，Diego Ongaro 在就读博士期间，深入研究 Paxos 协议后提出了 [Raft](1%20一切皆项目/搁置中/Q2：做CS的经典lab%201/Q2：做CS的经典lab/Raft.md) 协议，旨在提供更为易于理解的共识算法。Raft 的宗旨在于可实践性和可理解性，并且相比 Paxos 几乎没有牺牲多少性能。