【问题标题】:Distributed eventual consistency Key Value Store分布式最终一致性键值存储
【发布时间】:2017-05-16 02:08:16
【问题描述】:

我发现很难说服自己使用 DynamoDB 等复杂设计优于简单复制策略的优势。

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

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

但是,为什么我们不能简单地执行以下操作:

  1. 对于写入,客户端将向所有服务器发出写入命令。所以所有的服务器都会按照相同的顺序执行客户端的写命令。它会在服务器提交写入之前回复客户端。
  2. 对于读取,客户端只会进行循环,一次只有一个服务器会处理读取命令。 (其他服务器看不到读取命令) 是的,客户端可能会遇到临时过时的数据,但最终所有副本都将拥有相同的数据集,这与 DynamoDB 的语义相同。

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

【问题讨论】:

    标签: amazon-dynamodb distributed-system key-value-store eventual-consistency


    【解决方案1】:

    您的策略有一些缺点,但它们的确切性质取决于您未涵盖的细节。

    一个明显的例子是处理网络分段。也就是说,当您的网络的一部分与另一部分分割(断开)时。

    在这种情况下,当您尝试将一些数据写入服务器时,您有两个选择如何做出反应,但都失败了。您可能只是假设它有效,然后继续,好像一切都很好。如果您这样做,并且服务器稍后恢复联机,则读取可能会返回陈旧数据。

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

    为了防止这些问题,许多系统(包括 Paxos,如果没记错的话)使用某种基于“投票”的系统。也就是说,您尝试写入所有服务器。当且仅当大多数服务器确认它们已收到写入时,您才认为写入完成。同样,在读取时,您尝试从所有服务器中读取,并且当且仅当大多数服务器都同意该值时,您才认为该值正确读取。

    这样,在任何给定时间,最多不到一半的服务器可以离线,您仍然可以读取和写入数据。同样,如果您有几台服务器的反应比其他服务器慢一点,这不会降低整体操作速度。

    当然,您需要填写很多细节来创建一个工作系统——但事实仍然是基本概念非常简单,如上所述。

    【讨论】:

    • 您好,感谢您的回复!是的,这个简单的设计并没有像paxos/raft那样提供序列化。它为用户提供了最终的一致性。是的,用户可以暂时读取过时的数据。但最终所有副本都将拥有相同的数据集。我想我需要改写我的问题。我应该将它与像 DynamoDB 这样的系统进行比较,后者也是最终一致性键/值存储。但是 DynamoDB 涉及到非常复杂的冲突协调、向量时间戳等。与我的简单设计相比,它有什么优势?
    猜你喜欢
    • 2012-04-05
    • 1970-01-01
    • 1970-01-01
    • 2015-06-05
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多