分布式最终一致性密钥库

Question

我发现很难说服自己使用像DynamoDB这样的复杂设计，而不是简单的复制策略。

假设我们希望在5个服务器上构建一个分布式密钥/值数据存储。(每个服务器都有完全相同的副本)。

像DynamoDB一样，最终一致性系统通常使用复杂的冲突协调、向量时间戳等来实现最终的一致性。

但相反，为什么我们不能简单地做以下几点：

1. 对于写，客户端将向所有服务器发出写命令。因此，所有服务器都将以相同的顺序执行客户端的写命令。它将在服务器提交写入之前回复客户端。
2. 对于read，客户端将只执行一个循环，每次只有一个服务器负责读取命令。(其他服务器不会看到read命令)是的，客户端可能会经历暂时陈旧的数据，但最终所有副本都将拥有相同的数据集，这与DynamoDB具有相同的语义。

与复杂的DynamoDB相比，这种简单的设计有什么缺点？

Answer 1

您的策略有几个缺点，但它们的确切性质取决于您尚未涵盖的细节。

一个明显的例子是处理网络分割。也就是说，当网络的一个部分从另一个部分被分割(断开)时。

在本例中，当您尝试向服务器写入一些数据时，您有几个选择来说明如何作出反应，但这失败了。你可能只是假设它起作用了，然后继续下去，好像一切都很好一样。如果您这样做，并且服务器稍后返回在线，读取可能会返回陈旧的数据。

为了防止这种情况，您可以将失败的写入视为真正的失败，并拒绝接受写入，直到/除非所有服务器都确认了写入。不幸的是，这使得整个系统变得相当脆弱--事实上，比没有复制的系统脆弱得多(因为如果任何服务器断线，你就不能再写了)。它还有一个问题:它将写吞吐量限制在最慢服务器的(当前)速度上，所以即使它们都在工作，除非它们完全平衡(不太可能发生)，否则就是在浪费容量。

为了防止这些问题，许多系统(包括Paxos，如果内存服务)使用某种基于“投票”的系统。也就是说，您试图写入所有服务器。只有当大多数服务器确认它们已经收到写入时，您才会认为写入是完整的。同样，在读取时，您尝试从所有服务器读取，并且只有在大多数服务器都同意读取值的情况下，才考虑正确读取值。

这样，最多只有一半的服务器可以在任何给定的时间离线，而且您仍然可以读取和写入数据。同样，如果有几个服务器的反应比其他服务器慢一点，那么总体上不会减慢操作。

当然，您需要填写相当多的细节才能创建一个有效的系统--但事实仍然是，基本概念非常简单，正如上面所概述的。