AWS DynamoDB 写后读一致性 - 理论上它是如何工作的？

Question

大多数nosql解决方案仅使用最终一致性，并且考虑到DynamoDB将数据复制到三个数据中心，如何保持写后读一致性？

解决此类问题的通用方法是什么？我认为这很有趣，因为即使在 MySQL 复制中，数据也是异步复制的。

Answer 1

我将使用 MySQL 来说明答案，因为您提到了这一点，但显然我们都没有暗示 DynamoDB 在 MySQL 上运行。

在具有一个 MySQL 主服务器和任意数量从服务器的单个网络中，答案似乎非常简单——为了最终一致性，从随机选择的从服务器中获取答案；为了实现写后读一致性，始终从主服务器获取答案。

即使在MySQL复制中数据也是异步复制的

该说法有一个重要的例外，我怀疑它很可能比这里的任何其他替代方案更接近 DynamoDB 的现实：在与 MySQL 兼容的Galera 集群中，主节点之间的复制是同步的，因为主节点在每个节点上进行协作提交时的事务以及无法提交给所有主服务器的事务也会在其起源的主服务器上抛出错误。从技术上讲，这样的集群只能使用 2 个节点运行，但不应少于 3 个，因为当集群中出现分裂时，任何发现自己单独存在或位于小于原始集群大小一半的组中的节点都会滚动将自己变成一个无害的小球并拒绝提供查询服务，因为它知道自己属于孤立的少数，并且其数据不再可信。因此，在这样的分布式环境中，三是一个神奇的数字，可以避免灾难性的脑裂情况。

如果我们假设 DynamoDB 中的“三个地理上分布的副本”都是“主”副本，它们可能会按照同步主服务器的相同逻辑进行操作，就像您在 Galera 中发现的那样，因此解决方案本质上是相同的，因为该设置还允许任何或所有主站仍然拥有使用 MySQL 本机复制的传统异步从站。区别在于，如果您想要写后读一致性，您可以从当前连接到集群的任何主节点中获取数据，因为所有主节点都是同步的；否则从从站获取。

我能想到的第三种情况类似于循环复制配置中的三个地理上分散的 MySQL 主服务器，它再次支持每个主服务器的对向从属服务器，但存在其他问题，即主服务器不同步并且没有冲突解决能力——对于这个应用程序来说根本不可行，但为了讨论的目的，如果每个“对象”都有某种高精度的时间戳，目标仍然可以实现。当需要写后读一致性时，这里的解决方案可能是系统提供响应以轮询所有主设备以查找最新版本，直到所有主设备都被轮询后才返回答案，或者从从设备读取为了最终的一致性。

本质上，如果有多个“写入主机”，那么主机似乎别无选择，只能在提交时进行协作，或者在一致读取时进行协作。

有趣的是，我认为，尽管您可以在在线评论文章中找到一些关于 DynamoDB 中两个读取一致性级别之间的定价差异的抱怨，但这种分析 - 即使与 Dy​​namoDB 内部的实际情况相脱离 -似乎确实证明了这种差异是合理的。

最终一致的只读副本本质上是无限可扩展的（即使使用MySQL，主服务器可以轻松地服务多个从服务器，每个从服务器也可以轻松地服务自己的多个从服务器，每个从服务器可以服务多个......无限） -after-write 不是无限可扩展的，因为根据定义，它似乎需要“更权威”的服务器的参与，无论具体意味着什么，因此在需要这种一致性级别的情况下，需要更高的读取价格。