在分布式系统中，与Paxos相关的更快的协议算法是什么？

Question

我在Paxos上读过Lamport的paper。我也听说过，由于性能原因，它在实践中并没有太多用处。在分布式系统中通常使用哪些算法来达成共识？

Answer 1

不确定这是否有用（因为这不是来自实际的生产信息），但在我们的“分布式系统”课程中，我们与Paxos一起研究了 Chandra-Toueg 和< strong> Mostefaoui-Raynal 算法（后者我们的教授特别喜欢）。

Answer 2

如果性能问题，请考虑您是否需要Paxos为您提供的所有强大的一致性保证。参见例如http://queue.acm.org/detail.cfm?id=1466448和http://incubator.apache.org/cassandra/。搜索优化后的Paxos让我受到欢迎，但我怀疑放松一些要求会比调整协议更多地为你买。

Answer 3

我运行的Paxos系统（支持真正非常大的网站）介于Basic-Paxos Multi-paxos之间。 我计划将其移至完整的Multi-Paxos实施。

Paxos并不像高吞吐量数据存储系统那么出色，但它通过提供领导者选举而擅长支持这些系统。例如，假设您有一个复制数据存储，出于性能原因需要单个主服务器。您的数据存储节点将使用Paxos系统来选择主服务器。

与Google Chubby一样，我的系统作为服务运行，也可以将数据存储为配置容器。 （我使用松散的配置;我听说Google使用Chubby进行DNS。）此数据不会像用户输入那样频繁更改，因此它不需要高吞吐量写入SLA。另一方面，阅读非常快，因为它是完全复制的，您可以从任何节点读取。

<强>更新

自写这篇文章以来，我已经升级了我的Paxos系统。我现在使用连锁共识协议作为主要共识系统。链系统仍然使用Basic-Paxos进行重新配置 - 包括在链成员变化时通知链节点。

Answer 4

查看Raft算法以获得一致性算法，该算法经过优化，易于理解和实现清晰。哦......它也很快。

https://ramcloud.stanford.edu/wiki/display/logcabin/LogCabin

https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf

Answer 5

您应该检查Apache Zookeeper项目。它被雅虎用于生产！和Facebook等。

http://hadoop.apache.org/zookeeper/

如果你寻找描述它的学术论文，它会在usenix ATC'10的论文中描述。共识协议（Paxos的变体）在DSN'11的论文中描述。

Answer 6

Google在下面的文章中记录了他们如何为他们的超级市场做快速的paxos：Link。

Answer 7

Paxos在共识协议的性能方面是最佳，至少在网络延迟的数量方面（通常是主要因素）。显然不可能在容忍高达 f 故障的同时可靠地达成共识，而无需在客户端请求之间至少（f-1）其他节点进行单次往返通信和相应的确认，Paxos达到了这个下限。无论实现如何，这都会对每个请求对基于共识的协议的延迟产生严格限制。特别是，Raft，Zab，Viewstamped Replication和共识协议上的所有其他变体都具有相同的性能约束。

从标准的Paxos（也是Raft，Zab，......）可以改进的一件事是，有一位杰出的领导者最终做的不仅仅是其工作的公平份额，因此最终会有点像瓶颈。有一种称为Egalitarian Paxos的协议可以将负载分散到多个领导者身上，虽然IMO的思维过于复杂，只适用于某些领域，并且仍然必须遵守每个请求中往返次数的下限。参见文章“在平等议会中有更多共识”由Moraru等人提供更多细节。

当您听说Paxos由于其糟糕的表现而很少被使用时，通常意味着共识本身由于性能不佳而很少使用，这是一个公平的批评：它是可能的如果您可以尽可能避免节点之间基于共识的协调，则可以实现更高的性能，因为这样可以实现水平可伸缩性。

讽刺的是，通过声称使用正确的共识协议但实际上做某些事情在某些情况下失败，也可以实现更好的性能。 Aphyr's blog充斥着这些失败的例子，这些失败并不像你想象的那样罕见，数据库实现已经通过“优化”将错误引入了良好的共识类协议，或者开发了类似于共识的协议，不能以某种微妙的方式完全纠正。这个东西很难。

Answer 8

当领导者疾驰时，使用Multi-Paxos，当听到大多数节点已将值写入磁盘时，它可以响应客户端写入。这样做既有效又高效，可以保持Paxos的一致性保证。

通常情况下，人们会使用类似paxos的东西（如zookeeper）作为外部服务（专用群集）来保持关键信息的一致性（谁锁定了什么，谁是领导者，谁在群集中，是什么配置然后运行一个不太严格的算法，一致性保证较少，这取决于应用程序细节（例如矢量时钟和合并的兄弟）。简短的电子书distributed systems for fun and profit是对备选方案的一个很好的概述。

请注意，许多数据库通过使用有风险的默认值来竞争速度，这些默认值存在一致性并且可能会丢失网络分区下的数据。 Aphry blog series on Jepson显示是否熟知openouce系统松散数据。人们不能欺骗CAP定理;如果您为安全配置系统，那么他们最终会执行与paxos相同的消息传递和相同的磁盘写入。所以你真的不能说Paxos很慢你必须说＆＃34;系统的一部分需要在网络分区下保持一致性，每个操作需要最少数量的消息和磁盘刷新，而且速度很慢＃34;

Answer 9

有两种通用的区块链共识系统：

1. 在给定的一组定义下产生明确100％最终性的那些 验证器
2. 那些不提供100％最终确定性而是 依靠高确定性的可能性。

第一代区块链共识算法（工作量证明，权益证明和BitShares的委托权益证明）只能提供随着时间增长而增加的最终确定性的可能性。从理论上讲，有人可以支付足够的钱来开采替代的“更长的”比特币区块链，这种区块链可以一直追溯到创世纪。

最近的共识算法，无论HashGraph, Casper, Tendermint, or DPOS BFT是否都采用Paxos和相关共识算法的悠久原则。在这些模型下，只要超过1/3的参与者都诚实，就有可能在所有网络条件下达到明确的结局。

客观，明确的100％终结是所有希望支持区块链间通信的区块链的关键属性。如果没有100％的最终确定性，则一条链上的还原可能会在所有相互关联的链上产生不可调节的涟漪效应。

更多recent protocols的抽象协议包括：

1. 建议区块
2. 所有参与者都承认阻止（预先承诺）
3. 所有参与者都将acknowledge +发送给他们预先承诺 （承诺）
4. 一个节点收到⅔+个承诺后，一个块才是最后一个
5. 除非⅓+，否则可以保证就定案达成一致 是坏的，并且不良行为的证据可供所有人使用

正是协议中的技术差异导致了对用户体验的现实影响。其中包括诸如最终确定的延迟，最终确定的程度，带宽以及证明生成/验证开销。

查找有关eos here委派的股权证明的更多详细信息

Answer 10

Raft更易于理解，是Paxos的更快替代方案。使用Raft的最流行的分布式系统之一是Etcd。 Etcd是Kubernetes中使用的分布式存储。

在容错方面等同于Paxos。