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 宕机时，整个系统就无法 ...

背景论文从事件开始讲起，进程的执行被看作为一连串事件的持续发生，随后事件的排序问题很自然的被提出来，正如一致性模型与共识一文中，对一致性的探讨。其目的是对事件的发生确定一个合理的顺序，这种顺序的确立，对于一个进程内部发生的事件通常是比较容易的，但是当涉及到不同进程上的事件，通常便没有那么直观。 「Happened Before」现实生活当中，事件的先后顺序往往依赖物理时钟，而物理时钟不可能百分百精确，因此，Lamport 在定义事件之间的关系的时候特意避开了物理时间。这就是著名的「Happened Before」关系（用符号“→”来表示） 在上图中，我们尝试对消息发送事件和消息接收事件进行排序。 在进程Q内部，q2表示一个消息接收事件，q4表示另一个消息发送事件，q2排在q4前面执行，所以q2→q4。 p1和q2分别表示同一个消息的发送事件和接收事件，所以p1→q2；同理，q4→r3。 “happened before”满足传递关系。由p1→q2，q2→q4和q4→r3，可以推出p1→r3。 但是这里的 “happened before” 关系，是一种偏序关系。比如p1和q1两个 ...