blocks|key|1369278|text|查看针对共识算法的Raft算法，该算法经过优化，易于理解和实现清晰。哦..。它也是相当快的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1369279|https://ramcloud.stanford.edu/wiki/display/logcabin/LogCabin|offset|length|1369280|https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf|1369281|entityMap|0|LINK|mutability|MUTABLE|url|1^0|0|0|1O|0|0|0|21|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@$D|R|E|S|1|T]]|A|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@$D|V|E|W|1|X]]|A|$]]|$1|H|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|C]]|O|$5|K|L|M|A|$N|G]]]]

Check out the Raft algorithm for a consensus algorithm that is optimized for ease of understanding and clarity of implementation. Oh... it is pretty fast as well.

<a href="https://ramcloud.stanford.edu/wiki/display/logcabin/LogCabin" rel="nofollow">https://ramcloud.stanford.edu/wiki/display/logcabin/LogCabin</a>

<a href="https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf" rel="nofollow">https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf</a>

blocks|key|1154031|text|如果性能是一个问题，请考虑是否需要Paxos为您提供的所有强一致性保证。例如，参见http://queue.acm.org/detail.cfm?id=1466448和http://incubator.apache.org/cassandra/。在Paxos+optimised上搜索会给我带来更多的点击量，但我怀疑放松一些要求会比调整协议带来更多的好处。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1154032|entityMap|0|LINK|mutability|MUTABLE|url|http://queue.acm.org/detail.cfm?id=1466448|1|http://incubator.apache.org/cassandra/^0|15|16|0|2C|12|1|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]|$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]]]

If performance is an issue, consider whether you need all of the strong consistency guarantees Paxos gives you. See e.g. <a href="http://queue.acm.org/detail.cfm?id=1466448" rel="nofollow noreferrer">http://queue.acm.org/detail.cfm?id=1466448</a> and <a href="http://incubator.apache.org/cassandra/" rel="nofollow noreferrer">http://incubator.apache.org/cassandra/</a>. Searching on Paxos optimised gets me hits, but I suspect that relaxing some of the requirements will buy you more than tuning the protocol.

blocks|key|1369180|text|您应该检查Apache+Zookeeper项目。它在生产中被Yahoo！以及Facebook等。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1369181|http://hadoop.apache.org/zookeeper/|offset|length|1369182|如果你寻找描述它的学术论文，它在usenix+ATC'10的一篇论文中描述。共识协议(Paxos的变体)在DSN'11的一篇论文中描述。|1369183|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|Z|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@$D|Q|E|R|1|S]]|A|$]]|$1|F|3|G|5|6|7|T|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|C]]]]

You should check the Apache Zookeeper project. It is used in production by Yahoo! and Facebook among others.

<a href="http://hadoop.apache.org/zookeeper/" rel="nofollow">http://hadoop.apache.org/zookeeper/</a>

If you look for academic papers describing it, it is described in a paper at usenix ATC'10. The consensus protocol (a variant of Paxos) is described in a paper at DSN'11.

blocks|key|1369227|text|谷歌在下面的论文中记录了他们是如何为他们的巨型商店做快速paxos的：Link。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1369228|entityMap|0|LINK|mutability|MUTABLE|url|http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/pubs/archive/36971.pdf^0|Z|4|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Google documented how they did fast paxos for their megastore in the following paper: <a href="http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/pubs/archive/36971.pdf" rel="nofollow">Link</a>.

blocks|key|1369367|text|使用Multi-Paxos，当领导者在奔跑时，当它听说大多数节点已经将值写入磁盘时，它可以响应客户端写入。这是为了维护Paxos提供的一致性保证所能做到的最好、最有效的方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1369368|通常，人们使用paxos之类的东西(比如zookeeper+)作为外部服务(专用集群)来保持关键信息的一致性(谁锁定了什么，谁是领导者，谁在集群中，集群的配置是什么)，然后运行一个不那么严格的算法，其一致性保证较少，依赖于应用程序细节(例如矢量时钟和合并的兄弟节点)。这本简短的电子书distributed+systems+for+fun+and+profit很好地概述了替代方案。|offset|length|1369369|请注意，许多数据库通过使用有风险的缺省值来竞争速度，这些缺省值存在一致性风险，并且可能会在网络分区下丢失数据。Aphry+blog+series+on+Jepson显示是否了解开源系统的松散数据。不能欺骗CAP定理；如果您为了安全而配置系统，那么它们最终会像paxos一样执行相同的消息传递和相同的磁盘写入。所以你真的不能说Paxos很慢，你必须说“在网络分区下需要一致性的系统的一部分，每个操作需要最小数量的消息和磁盘刷新，这是很慢的”。|1369370|entityMap|0|LINK|mutability|MUTABLE|url|http://book.mixu.net/distsys/|1|http://aphyr.com/tags/jepsen^0|0|3Y|12|0|0|1J|R|1|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@$D|T|E|U|1|V]]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]]|A|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]|P|$5|K|L|M|A|$N|Q]]]]

With Multi-Paxos when the leader is galloping it can respond to the client write when it has heard that the majority of nodes have written the value to disk. This is as good and efficient as you can get to maintain the consistency guarantees that Paxos makes. 

Typically though people use something paxos-like such as zookeeper as an external service (dedicated cluster) to keep critical information consistent (who has locked what, who is leader, who is in a cluster, what's the configuration of the cluster) then run a less strict algorithm with less consistency guarantees which relies upon application specifics (eg vector clocks and merged siblings). The short ebook <a href="http://book.mixu.net/distsys/" rel="nofollow" title="distributed systems for fun and profit">distributed systems for fun and profit</a> as a good overview of the alternatives. 

Note that lots of databases compete on speed by using risky defaults which risk consistency and can loose data under network partitions. The <a href="http://aphyr.com/tags/jepsen" rel="nofollow">Aphry blog series on Jepson</a> shows whether well know opensouce systems loose data. One cannot cheat the CAP Theorem; if you configure systems for safety then they end up doing about the same messaging and same disk writes as paxos. So really you cannot say Paxos is slow you have to say "a part of a system which needs consistency under network partitions requires a minimum number of messages and disk flushes per operation and that is slow".

blocks|key|1369390|text|Raft更容易理解，也更快，是Paxos的替代品。使用Raft的最流行的分布式系统之一是Etcd。Etcd是Kubernetes中使用的分布式存储。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1369391|它在容错性上等同于Paxos。|1369392|entityMap|0|LINK|mutability|MUTABLE|url|https://raft.github.io/|1|https://github.com/etcd-io/etcd^0|0|4|0|18|4|1|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]|$A|T|B|U|1|V]]|C|$]]|$1|D|3|E|5|6|7|W|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]]]

<a href="https://raft.github.io/" rel="nofollow noreferrer">Raft</a> is more understandable, and faster alternative of Paxos. One of the most popular distributed systems which uses Raft is <a href="https://github.com/etcd-io/etcd" rel="nofollow noreferrer">Etcd</a>. Etcd is the distributed store used in Kubernetes. 

It's equivalent to Paxos in fault-tolerance.

I've read Lamport's <a href="http://research.microsoft.com/en-us/um/people/lamport/pubs/paxos-simple.pdf" rel="noreferrer">paper</a> on Paxos. I've also heard that it isn't used much in practice, for reasons of performance. What algorithms are commonly used for consensus in distributed systems?

What are the faster Paxos-related algorithms for consensus in distributed systems?

分布式存储

Kubernetes

数据库

我在Paxos上读过Lamport的。我还听说，出于性能方面的原因，它在实践中使用得并不多。在分布式系统中，共识通常使用哪些算法？

问在分布式系统中，与Paxos相关的更快的共识算法是什么？
EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在分布式系统中，与Paxos相关的更快的共识算法是什么？EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在分布式系统中，与Paxos相关的更快的共识算法是什么？
EN