分布式一致性算法Raft论文（3）——Paxos的问题

3 What’s wrong with Paxos?

 难以理解；历史实际工作中花费时间长

        Over the last ten years, Leslie Lamport’s Paxos protocol [15] has become almost synonymous with consensus: it is the protocol most commonly taught in courses, and most implementations of consensus use it as a starting point. Paxos first defines a protocol capable of reaching agreement on a single decision, such as a single replicated log entry. We refer to this subset as single-decree Paxos. Paxos then combines multiple instances of this protocol to facilitate a series of decisions such as a log (multi-Paxos). Paxos ensures both safety and liveness, and it supports changes in cluster membership. Its correctness has been proven, and it is efficient in the normal case.

        在过去十年中，Leslie Lamport的Paxos协议[15]几乎成为共识的同义词：它是课程中最常用的协议，大多数共识的实现都将其作为起点。Paxos首先定义了一个能够就单个决策达成一致的协议，例如单个复制日志条目。我们将该子集称为单命令Paxos。然后，Paxos将该协议的多个实例组合起来，以促进一系列决策，例如日志（multi-Paxos）。Paxos确保了安全性和活性，并且支持集群成员资格的更改。它的正确性已经被证明，并且在正常情况下是有效的。

        Unfortunately, Paxos has two significant drawbacks. The first drawback is that Paxos is exceptionally difficult to understand. The full explanation [15] is notoriously opaque; few people succeed in understanding it, and only with great effort. As a result, there have been several
attempts to explain Paxos in simpler terms [16, 20, 21]. These explanations focus on the single-decree subset, yet they are still challenging. In an informal survey of attendees at NSDI 2012, we found few people who were comfortable with Paxos, even among seasoned researchers.
We struggled with Paxos ourselves; we were not able to understand the complete protocol until after reading several simplified explanations and designing our own alternative protocol, a process that took almost a year.

        不幸的是，Paxos有两个显著的缺点。第一个缺点是Paxos非常难以理解。完整的解释[15]是出了名的不透明；很少有人能够理解它，而且只有付出巨大的努力。因此，出现了几个问题
试图用更简单的术语解释Paxos[16,20,21]。这些解释侧重于单一法令子集，但仍然具有挑战性。在2012年NSDI的一项非正式调查中，我们发现很少有人对Paxos感到满意，即使是经验丰富的研究人员。 我们自己也在与帕克斯斗争；在阅读了几篇简化的解释并设计了我们自己的替代方案之后，我们才能够理解完整的方案，这一过程花了将近一年的时间。

        We hypothesize that Paxos’ opaqueness derives from its choice of the single-decree subset as its foundation. Single-decree Paxos is dense and subtle: it is divided into two stages that do not have simple intuitive explanations and cannot be understood independently. Because of this,
it is difficult to develop intuitions about why the singledecree protocol works. The composition rules for multiPaxos add significant additional complexity and subtlety. We believe that the overall problem of reaching consensus on multiple decisions (i.e., a log instead of a single entry) can be decomposed in other ways that are more direct and obvious.

        我们假设Paxos的不透明度来源于其对单一法令子集的选择作为其基础。单一 Paxos是密集而微妙的：它分为两个阶段，没有简单的直观解释，无法独立理解。因此，很难对SingleDecise协议的工作原理做出直观的解释。多路径的组合规则增加了显著的额外复杂性和微妙性。我们认为，就多个决策（即，一个日志而不是一个条目）达成共识的总体问题可以通过其他更直接和明显的方式进行分解。

        The second problem with Paxos is that it does not provide a good foundation for building practical implementations. One reason is that there is no widely agreedupon algorithm for multi-Paxos. Lamport’s descriptions are mostly about single-decree Paxos; he sketched possible approaches to multi-Paxos, but many details are missing. There have been several attempts to flesh out and optimize Paxos, such as [26], [39], and [13], but these differ from each other and from Lamport’s sketches. Systems such as Chubby [4] have implemented Paxos-like algorithms, but in most cases their details have not been published.

        Furthermore, the Paxos architecture is a poor one for building practical systems; this is another consequence of the single-decree decomposition. For example, there is little benefit to choosing a collection of log entries independently and then melding them into a sequential log; this just adds complexity. It is simpler and more efficient to design a system around a log, where new entries are appended sequentially in a constrained order. Another problem is that Paxos uses a symmetric peer-to-peer approach at its core (though it eventually suggests a weak form of
leadership as a performance optimization). This makes sense in a simplified world where only one decision will be made, but few practical systems use this approach. If a series of decisions must be made, it is simpler and faster to first elect a leader, then have the leader coordinate the
decisions.
        As a result, practical systems bear little resemblance to Paxos. Each implementation begins with Paxos, discovers the difficulties in implementing it, and then develops a significantly different architecture. This is timeconsuming and error-prone, and the difficulties of understanding Paxos exacerbate the problem. Paxos’ formulation may be a good one for proving theorems about its correctness, but real implementations are so different from Paxos that the proofs have little value. The following comment from the Chubby implementers is typical:
        There are significant gaps between the description of the Paxos algorithm and the needs of a real-world system. . . . the final system will be based on an unproven protocol [4].

        Because of these problems, we concluded that Paxos does not provide a good foundation either for system building or for education. Given the importance of consensus in large-scale software systems, we decided to see if we could design an alternative consensus algorithm
with better properties than Paxos. Raft is the result of that experiment.