我已经阅读了 Lamport关于 Paxos的论文。我还听说，出于性能原因，它在实践中的使用并不多。分布式系统中共识常用的算法有哪些？
问问题
4347 次
10 回答
4
不确定这是否有帮助（因为这不是来自实际的生产信息），但在我们的“分布式系统”课程中，我们学习了 Paxos、Chandra-Toueg和Mostefaoui-Raynal算法（后者是我们的教授特别喜欢）。
于 2010-01-04T19:46:41.830 回答
3
查看 Raft 算法，了解经过优化以易于理解和清晰实施的共识算法。哦......它也很快。
https://ramcloud.stanford.edu/wiki/display/logcabin/LogCabin
https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf
于 2013-09-10T05:58:07.567 回答
2
我运行的 Paxos 系统（它支持非常非常大的网站）介于 Basic-Paxos Multi-paxos 之间。我计划将它转移到一个完整的 Multi-Paxos 实现中。
Paxos 不像高吞吐量数据存储系统那么出色，但它通过提供领导选举来支持这些系统方面表现出色。例如，假设您有一个复制的数据存储，出于性能原因您需要一个主控。您的数据存储节点将使用 Paxos 系统来选择主节点。
像 Google Chubby 一样，我的系统作为服务运行，也可以将数据存储为配置容器。（我松散地使用配置；我听说 Google 将 Chubby 用于 DNS。）这些数据不会像用户输入那样经常更改，因此它不需要高吞吐量的写入 SLA。另一方面，读取速度非常快，因为它是完全复制的，您可以从任何节点读取。
更新
自从写这篇文章以来，我已经升级了我的 Paxos 系统。我现在使用链式共识协议作为主要共识系统。链系统仍然使用 Basic-Paxos 进行重新配置——包括在链成员发生变化时通知链节点。
于 2012-04-14T07:15:44.163 回答
2
如果性能是一个问题，请考虑是否需要 Paxos 为您提供的所有强一致性保证。参见例如http://queue.acm.org/detail.cfm?id=1466448和http://incubator.apache.org/cassandra/。搜索优化的 Paxos 让我很满意，但我怀疑放宽一些要求比调整协议更能给你带来好处。
于 2010-01-04T19:57:19.250 回答
2
Paxos 在共识协议的性能方面是最佳的，至少在网络延迟的数量方面（这通常是主要因素）。在客户端请求和相应确认之间，如果没有与至少(f-1)个其他节点的单次往返通信，显然不可能可靠地达成共识，同时容忍多达f次失败，而 Paxos 实现了这个下限。这为每个请求对基于共识的协议的延迟提供了一个硬性限制，无论实施如何。特别是，Raft、Zab、Viewstamped Replication 和所有其他共识协议的变体都具有相同的性能约束。
可以从标准 Paxos（还有 Raft、Zab 等）改进的一件事是，有一个杰出的领导者最终完成了超出其公平份额的工作，因此最终可能会成为一个瓶颈。有一个称为 Egalitarian Paxos 的协议将负载分散到多个领导者之间，尽管它非常复杂 IMO，仅适用于某些域，并且仍然必须遵守每个请求中往返次数的下限。有关详细信息，请参阅Moraru 等人的论文“平等主义议会中有更多共识” 。
当你听说 Paxos 因为性能不佳而很少使用时，通常意味着共识本身由于性能不佳而很少使用，这是一个公平的批评：如果你能避免需要，就有可能获得更高的性能尽可能多地在节点之间进行基于共识的协调，因为这允许水平可扩展性。
讽刺的是，通过声称使用正确的共识协议但实际上在某些情况下会失败的事情，也可以实现更好的性能。Aphyr 的博客中充斥着这些失败的例子，这些失败并不像你想象的那么罕见，其中数据库实现要么通过“优化”将错误引入良好的类似共识的协议中，要么开发了未能实现的自定义类似共识的协议以某种微妙的方式完全正确。这东西很难。
于 2016-12-13T12:24:01.600 回答
1
您应该检查 Apache Zookeeper 项目。它被 Yahoo! 用于生产。和 Facebook 等。
http://hadoop.apache.org/zookeeper/
如果您寻找描述它的学术论文，它在 useenix ATC'10 的一篇论文中有所描述。DSN'11 上的一篇论文描述了共识协议（Paxos 的一种变体）。
于 2011-03-08T01:01:29.570 回答
1
谷歌在以下论文中记录了他们如何为他们的大型商店执行快速 paxos：链接。
于 2011-10-26T20:33:00.413 回答
0
使用 Multi-Paxos，当领导者疾驰时，它可以在听到大多数节点已将值写入磁盘时响应客户端写入。这是尽可能好的和高效的，可以保持 Paxos 所做的一致性保证。
通常，尽管人们使用类似 paxos 的东西（例如 zookeeper）作为外部服务（专用集群）来保持关键信息的一致性（谁锁定了什么，谁是领导者，谁在集群中，集群的配置是什么）然后运行不太严格的算法具有较少的一致性保证，它依赖于应用程序的细节（例如矢量时钟和合并的兄弟姐妹）。简短的电子书分布式系统的乐趣和利润作为替代方案的一个很好的概述。
请注意，许多数据库通过使用有风险的默认设置来竞争速度，这些默认设置可能会导致一致性风险，并且可能会在网络分区下丢失数据。Jepson 上的Aphry 博客系列展示了众所周知的 opensouce 系统是否会丢失数据。不能欺骗 CAP 定理；如果您为安全配置系统，那么它们最终会执行与 paxos 相同的消息传递和相同的磁盘写入操作。所以你真的不能说 Paxos 很慢，你必须说“系统的一部分需要在网络分区下保持一致性，每次操作需要最少数量的消息和磁盘刷新，这很慢”。
于 2014-10-24T14:22:14.790 回答
0
有两种通用的区块链共识系统：
- 那些在给定一组定义的验证器的情况下产生明确的 100% 确定性
- 那些不提供 100% 确定性而是依赖于高确定性的方法。
第一代区块链共识算法（工作证明、股权证明和比特股的委托股权证明）仅提供随时间增长的高确定性概率。从理论上讲，有人可以支付足够的钱来挖掘一个可以追溯到创世的替代“更长”比特币区块链。
最近的共识算法，是否HashGraph, Casper, Tendermint, or DPOS BFT都采用了历史悠久的Paxos共识算法和相关的共识算法。在这些模型下，只要超过 2/3 的参与者是诚实的，就可以在所有网络条件下达到明确的确定性。
客观和明确的 100% 确定性是所有希望支持跨链通信的区块链的关键属性。如果没有 100% 的最终确定性，一条链的回归可能会对所有相互连接的链产生不可调和的连锁反应。
这些更多的抽象协议recent protocols涉及：
- 提议区块
- 所有参与者确认区块（预先承诺）
- 当⅔+向他们发送预先承诺（承诺）时，所有参与者都会确认
- 一旦节点收到⅔+承诺，一个区块就是最终的
- 除非 ⅓+ 是不良行为并且所有人都可以获得不良行为的证据，否则可以保证就最终性达成一致协议
协议中的技术差异会对用户体验产生实际影响。这包括诸如直到最终确定的延迟、确定程度、带宽和证明生成/验证开销等内容。
在此处查找有关 eos 委托权益证明的更多详细信息
于 2019-11-13T08:22:10.317 回答