大部分nosql方案只使用最终一致性，鉴于DynamoDB将数据复制到三个数据中心，读写一致性是如何维护的？
解决此类问题的通用方法是什么？我认为这很有趣，因为即使在 MySQL 复制中，数据也是异步复制的。
问问题
6276 次
3 回答
3
我将使用 MySQL 来说明答案，因为您提到了它，但显然，我们都没有暗示 DynamoDB 在 MySQL 上运行。
在具有一个 MySQL 主服务器和任意数量的从服务器的单一网络中，答案似乎非常简单——为了最终的一致性，从随机选择的从服务器中获取答案；为了写后读的一致性，总是从主人那里获取答案。
即使在 MySQL 复制中，数据也是异步复制的
该声明有一个重要的例外，我怀疑它很可能比这里的任何其他替代方案更接近 DynamoDB 的现实：在与 MySQL 兼容的Galera 集群中，master 之间的复制是同步的，因为 master 在提交时协作处理每个事务，并且无法提交给所有 master 的事务也会在其起源的 master 上引发错误。像这样的集群在技术上只能使用 2 个节点运行，但不应少于 3 个，因为当集群中出现分裂时，任何发现自己单独或在小于原始集群大小一半的组中的节点都会滚动将自己变成一个无害的小球并拒绝为查询提供服务，因为它知道自己处于孤立的少数群体中，并且不再可以信任其数据。因此，在这样的分布式环境中，三是一个神奇的数字，可以避免灾难性的脑裂情况。
如果我们假设 DynamoDB 中的“三个地理上分布的副本”都是“主”副本，那么它们可能会沿着与 Galera 相同的同步主服务器的逻辑运行，因此解决方案基本上是相同的，因为该设置还允许任何或所有主服务器仍然具有使用 MySQL 本机复制的传统对向异步从服务器。不同之处在于，如果您想要读写一致性，您可以从当前连接到集群的任何 master 中获取，因为它们都是同步的；否则从奴隶获取。
我能想到的第三种情况类似于循环复制配置中的三个地理上分散的 MySQL 主服务器，它再次支持每个主服务器的对向从服务器，但存在主服务器不同步并且没有冲突解决能力——对于这个应用来说根本不可行，但为了讨论的目的，如果每个“对象”都有某种高度精确的时间戳，目标仍然可以实现。当需要写后读一致性时，这里的解决方案可能是为响应提供服务的系统轮询所有主设备以找到最新版本，直到所有主设备都被轮询后才返回答案，或者从从属设备读取为了最终的一致性。
本质上，如果有多个“写入大师”，那么大师似乎别无选择，只能在提交时协作，或者在一致读取时协作。
有趣的是，我认为，尽管您可以在在线评论文章中找到一些关于 DynamoDB 中两个读取一致性级别之间定价差异的抱怨，但这种分析——即使与 DynamoDB 内部的现实脱节——似乎确实证明了这种差异。
最终一致的只读副本本质上是无限可扩展的（即使在 MySQL 中，master 可以轻松地为多个 slave 提供服务，每个 slave 也可以轻松地为自己的多个 slave 提供服务，每个 slave 可以为多个... ad infinitum提供服务）但是读取-after-write 不是无限可扩展的，因为根据定义，它似乎需要“更权威”的服务器的参与，无论这具体意味着什么，因此证明需要这种一致性级别的读取的更高价格是合理的。
于 2013-11-12T00:44:53.863 回答
0
我会告诉你 DynamoDB 是如何做到这一点的。没有猜测。
为了向客户端确认写入请求，写入必须在该分区的三个存储节点中的两个上是持久的。两个存储节点之一必须是该分区的领导节点。第三个存储节点可能也已更新，但万一发生了什么事情，它可能不会。DynamoDB 将尽快更新该版本。
当您请求强一致性读取时，该读取来自存储项目的分区的领导存储节点。
于 2021-06-16T20:44:13.410 回答
-1
我知道我在被问到很久之后才回答这个问题，但我认为可以提供一些有用的信息......
在分布式数据库中，“主”的概念不再特别相关（至少对于读/写而言）。每个节点都应该能够执行读取和写入，以便读取/写入性能随着机器数量的增加而增加。如果您希望在写入后立即读取正确，则您写入然后读取的机器数量必须大于系统中的机器总数。
示例：如果您只写入 1 台机器，那么您必须从所有机器中读取以确保您的数据不会过时。或者，如果您写入 2 台机器（在本例中为 quorum），您可以在 quorum 上执行读取并保证您的数据是最新的。
注意：当系统中的一部分节点崩溃时，这些假设会发生变化。
于 2015-08-09T18:55:23.100 回答