Raft 是一种为了管理复制日志的一致性算法，它提供了与 Paxos 算法相同的功能与性能，而 Paxos 算法是为了最终唯一选定一个提案，有关 Paxos 的介绍，可以参考Paxos Made Simple 一文，为了提升可理解性，Raft 将一致性算法分解为几个关键模块，例如：领导者选举、日志复制和安全性，通过通过 Leader 来提供一个更强的一致性来减少需要考虑的状态数量。 介绍Raft 算法在许多方面与现有的一致性算法都很相似，但是它也有一些独特的特性： 强领导者：Raft 使用一种更强的领导能力形式。比如，日志条目只从领导人发送给其他的服务器。这种方式简化了对复制日志的管理并且使得 Raft 算法更加易于理解。 领导选举：Raft 通过随机超时时间来选举领导者，在解决冲突的时候会更加简单快捷。 成员关系调整：Raft 通过联合共识来处理集群成员变更的问题。 复制状态机一致性算法是从复制状态机的背景下提出的，其正确性主要来源于复制状态机的性质： 123任何初始状态一样的状态机，如果执行的命令序列一样，则最终达到的状态也一样。如果将此特性应用在多参与者进行协商共识上，可 ...

《Paxos Made Simple》是 Lamport 另一篇关于 Paxos 的论文，从一个一致性算法所需要满足的条件展开，向读者讲解 paxos 算法的合理性。 从整体上来说， Paxos 算法的目标就是要确保最终会有一个提案被选定，当提案被选定后，其他节点也会获取到被选定的提案。 在 Paxos 算法中存在三个角色： Proposer (发送提案) Acceptor (选定提案) Learner (获取最终选定的提案) 在具体的实现中，一个节点可能充当不同的角色，这里不关心角色与节点之间的转换，不同参与者之间可以通过首发消息来进行通信，当然通信时可能会遇到各种状况： 消息在传递时的延迟、丢失，但是假设并不会被篡改(非拜占庭式容错) 节点可能会宕机，长时间任务导致的对外不可用 网络分区 提案的选定首先从一个最简单的方式出发，如果只有一个 Acceptor 负责选定提案，多个 Proposer 来提交提案，那么只需要约定 Acceptor 选定接受到的第一个提案就行，这种方式非常的简单且易于理解，但是问题也很明显，存在单点问题，当Acceptor 宕机时，整个系统就无法 ...