distributed-computing - 什么时候使用Paxos这样的共识算法而不是Vector Clock？

Question

我已经阅读了很多有关确保分布式系统中节点之间一致性的不同策略的文章，但是在弄清楚何时使用哪种算法时遇到了一些麻烦。

我将在哪种系统上使用 vector 时钟？哪种系统最适合使用Paxos之类的东西？两者是互斥的吗？

Answer 1

有一个由2个节点组成的分布式系统，用于存储数据。数据被复制到两个节点，因此，如果一个节点死亡，则数据不会丢失(耐用性)并继续提供服务(可用性)。另外，您还希望您的2节点系统每秒能够处理两倍的请求(可伸缩性)。

假设对单个键的写入可以到达任何节点。您的客户端写“1”作为某个键的值，然后决定写“2”。第一次写到节点＃1。它将复制请求发布到节点2。但是，您存储“2”的请求早于复制请求到达节点＃2(记住，我们可以存储在任何节点上)。它存储“2”，向节点＃1发出带有“2”的复制请求，从中接收到具有“1”的复制请求，将其“2”更改为“1”，而节点＃1将其“1”更改为“2”。现在，存储节点之间的数据不一致。同样，如果节点＃1死亡，那么您所拥有的只是节点＃2，其值为“1”，同时您还记得在“1”之后发送了“2”，并且存储系统已确认已保存它。实际上，根据您对存储系统的期望(读取写入内容，单调读取内容等)，很多事情可能会“出错”，因此您需要一种方法来真正找出密钥的真实，良好和实际值(value)是，甚至防止系统以这种方式“破坏”数据。为此，存储系统需要知道在节点之间发生了什么之前发生的事情，或者甚至可能考虑到客户对事件顺序的看法。 Vector clocks和version vectors是实践中用于实现此目标的技术，或声称2个事件同时发生，因此您需要其他方法来决定它们的结果。

为了避免所有这些复杂性，您决定以不同的方式解决该问题:某个键的所有写操作都将到达一个节点(称为“领导者”)，并将这些写操作复制到另一个节点上。确实，这看起来像是一种更简单的方案:在一个节点(可能是一个进程)内，您拥有快速且行之有效的并发控制技术，可以轻松地对事件进行排序，可以以相同的顺序应用复制；而且，总是有权威的正确数据来源。唯一的问题是您的2个存储节点需要同意哪个节点是特定密钥的领导者。如果您有3个节点，其中一个节点死亡，则其他2个节点需要确定1)他们都认为旧领导者死亡，2)其中一个是新领导者。为此，存在共识协议(protocol)(Paxos，2-phase commit，Raft，Zab，3阶段提交等)。

为什么不总是选择不使用无领导者方案的单个领导者(以及共识协议(protocol))(以及像版本 vector 这样的排序机制)呢？协商领导需要花费时间(最多可能需要几秒钟或数十秒)，在此期间您的系统将不可用或在某些特殊模式下部分可用。无领导者也可以在其他一些条件下表现更好(例如，由于软件问题或网络问题导致领导者变慢:采用无领导者方法，其他节点可能会接替其职责)。随着参与者数量的增加，共识变得越来越困难，因此无领导者可能会更好地进行扩展。

最后，让我们逐字逐句浏览您的问题:

With what kind of system would I use something like a vector clock?

您可能想将版本 vector 用于无领导者分布式存储。您可能将 vector 时钟用于同一时钟(尽管它是 a worse fit；本文还建议您将其用于一致的快照，在通用分布式系统中实现 causal ordering等)。

Which system is ideal for using something like Paxos?

单领导者或多领导者分布式存储。很少更新数据(例如配置)，集群参与信息的数据库-如果此信息很关键，则八卦的扩展性更好。分布式锁。

Are the two mutually exclusive?

否。两者都可以用于解决相同的任务(例如，分布式存储)。可以将它们组合在一起(用于集群参与的Paxos，然后使用该知识来确定哪些节点构成最终一致的(通过版本 vector )系统中的仲裁)。