distributed-computing - paxos-避免在分布式系统中过度使用共识协议(protocol)

我是分布式系统的新手，正在阅读有关“简单的Paxos”的信息。它引起了很多争议，我正在考虑性能方面的问题。

假设您正在建立一个全局分布的数据库，其中几个位于不同位置的小型集群。减少跨站点通信的数量似乎很重要。

要使用共识，您肯定需要做出哪些决定？我唯一想到的就是确定是否要从网络中添加或删除一个节点(或一组节点？)。看来矢量时钟必须工作。另一个我不太确定的决定是写到同一位置的命令，但这是否应该由通过Paxos选举产生的领导者来完成？

最好避免让系统中的所有节点共同做出决定。每个本地集群中的几个节点能否参与跨集群决策，并且所有本地节点都使用本地Paxos进行通信以确定对跨站点问题的本地答案？如果网络未饱和，则等待时间将相同，但是跨站点网络流量将更轻。

假设您可以按行拆分数据库的表，然后将行的每个子集分配给节点的子集。在系统中的所有机器上使用Paxos选择一组节点来包含数据的每个子集是否正常，然后仅在这些节点之间运行Paxos来处理该数据子集的所有操作？

总而言之:人们是否还进行了其他与设计相关或算法上的优化来解决这一问题？

最佳答案

好的问题，好的见解!

是的，性能也是我的团队在实践中遇到的问题。我们维护一致的数据库和分布式锁管理器；通常用于所有写入，某些读取和集群成员更新的Paxos。
以下是我们所做的一些优化:

节点尽可能将转换发送给杰出的提议者/学习者(通过Paxos选举)，

决定写顺序，而

在等待来自先前实例的响应的同时进行了批量转换。 (但是批处理过多也会引起问题。)

我们曾考虑使用multi-paxos，但最终做了一些更酷的事情(请参见下文)。

通过这些优化，我们仍然会影响性能，因此我们将服务器分为三层。最底层是Paxos；它按照您的建议进行；即仅决定中间层的节点成员资格。中间层是内部自定义的高速链共识协议(protocol)，该协议(protocol)对数据库进行共识和排序。 (顺便说一句，可以将Chain-consensus视为Vertical Paxos。)顶层现在仅维护数据库/锁和客户端连接。这种设计导致了几个数量级的延迟和吞吐量的提高。


这两个使我想起了Google Spanner paper。如果您跳过有关时间的部分，则实际上是在全局执行2PC，在分片上执行Paxos。 (IIRC。)

关于distributed-computing - paxos-避免在分布式系统中过度使用共识协议(protocol)，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/16307122/