我发现很难说服自己使用像DynamoDB这样的复杂设计优于简单的复制策略。
假设我们想要在5台服务器上构建分布式键/值数据存储。 （每个服务器具有完全相同的副本）。
最终的一致性系统，如DynamoDB，通常使用复杂的冲突协调，矢量时间戳等来实现最终的一致性。
但相反，为什么我们不能简单地执行以下操作：
与简单的DynamoDB相比，这个简单设计的缺点是什么？
答案 0 :(得分：0)
您的策略有一些缺点，但它们的确切性质取决于您尚未涵盖的细节。
一个明显的例子是处理网络分段。也就是说，当您的网络的一部分与另一部分分段（断开连接）时。
在这种情况下，当您尝试将某些数据写入服务器时，您有几个选择可以做出反应，但这会失败。你可能只是认为它有效，并继续好像一切都很好。如果您这样做，并且服务器稍后重新启动，则读取可能会返回过时数据。
为了防止这种情况，您可以将写入失败视为真正的失败，并拒绝接受写入，直到/除非所有服务器都确认写入。不幸的是，这使整个系统变得非常脆弱 - 事实上，比你根本没有复制（因为如果任何）更脆弱（至少在写作方面）服务器离线，你不能再写了）。它还有一个问题：它将写入吞吐量限制为最慢服务器的（当前）速度，因此即使它们全部工作，除非它们完全平衡（不太可能发生），否则浪费能力。
为了防止这些问题，许多系统（包括Paxos，如果内存服务）使用某种＆＃34;投票＆＃34;基于系统。也就是说，您尝试写入所有服务器。当且仅当大多数服务器确认他们已收到写入时，才认为写入完成。同样，在读取时，您尝试从所有服务器读取数据，并且当且仅当大多数服务器同意该值时，才会认为值正确读取。
这样，在任何给定时间内，只有不到一半的服务器可以脱机，您仍然可以读写数据。同样，如果您有一些服务器的响应速度比其他服务器慢一点，那么整体操作的速度就不会慢下来。
当然，您需要填写相当多的细节来创建一个工作系统 - 但事实仍然是基本概念非常简单，如上所述。