不用Paxos的分布式系统，都是耍流氓
分布式系统，包括分布式存储、分布式文件系统、分布式数据库、分布式消息中间件、分布式计算框架等，其系统构建需要解决的一个共性难题就是如何在分布式环境下进行决策。
举个例子来理解一下：比如，节点1需要发消息给节点2，3，4，告诉他们需要把数据记录从A改成B。因此，节点1给节点2，3，4各发一个消息请求，然后等待消息回应。期望节点2，3，4各返回一个成功消息，这样就能认为数据记录修改成功了，节点1就可以进行下一步处理了。
但是，实际的情况会复杂得多，消息在网络上传输会存在延迟、丢包等问题，各节点上的进程会出现太忙无法及时回应、进程崩溃等问题。比如，由于网络抖动，节点2，3，4在5秒后才收到消息，并且都数据修改成功了，发生成功的消息回应给节点1. 节点1 又过了5秒才收到回应，这样从消息请求发送至消息回应收到，总计用了10秒。但节点1的超时时间设置为6秒，这样在第6秒的时候节点1已经认为节点2，3，4都不能成功了，本请求作为失败进行处理了，又过了4秒却收到成功的回应了，这种情况下怎么办？
那么节点1的超时时间，不要设置为6秒，就一直等待，不行吗? 如果一直等待，由于节点2，3，4 进程崩溃，根本就没有回应，会导致节点1一直挂死，因此也是不行的。
上述的场景，其实在分布式系统里面是非常常见的，由于网络、主机、进程随时都会出现各种故障，因此在分布式系统里，面对各种不确定的软硬件环境，如何做出正确的决策，让系统中各个组成部分始终保持对系统状态的共识，是分布系统最核心要解决的问题。这就是分布式系统的一致性算法(Consensus Algorithm)。
分布式一致性算法，最著名的是Paxos算法，由Lamport提出，使其获得2013年图灵奖。Paxos由Lamport于1998年在《The Part-Time Parliament》论文中首次公开，最初的描述使用希腊的一个小岛Paxos作为比喻，描述了Paxos小岛中通过决议的流程，并以此命名这个算法，但是这个描述理解起来比较有挑战性。后来在2001年，Lamport觉得同行不能理解他的幽默感，于是重新发表了朴实的算法描述版本《Paxos Made Simple》。自Paxos问世以来就持续垄断了分布式一致性算法，Paxos这个名词几乎等同于分布式一致性。Google的很多大型分布式系统都采用了Paxos算法来解决分布式一致性问题，如Chubby、Megastore以及Spanner等。
然而，Paxos的最大特点就是难，不仅难以理解，更难以实现。因此后续出现了Raft算法，对Paxos进行简化，使其易于理解、易于实现。Raft 算法要求对消息日志的完全串行写入，由于增加了这个前提条件，使得实现过程得到了简化。但Paxos算法本身，是没有这个约束的，因此可以简单理解为：其它算法都是Paxos的简化版，增加了某些特定的约束限制。
如果不用Paxos，或Raft等分布式算法，在一个分布式系统中，根本就无法保证状态的一致性。这是从分布式理论和算法层面就注定的结论。
验证一个分布式系统，是否正确实现了一致性算法，可以通过Jepsen 工具来检验。
无Paxos，不分布式！