简单英语的最终一致性答案

【问题标题】：Eventual consistency in plain English简单英语的最终一致性
【发布时间】：2012-04-22 03:22:42
【问题描述】：

我经常在关于 NoSQL、数据网格等的不同演讲中听到最终一致性。似乎最终一致性的定义在许多来源中有所不同（甚至可能取决于具体的数据存储）。

谁能简单解释一下最终一致性是什么笼统的术语，与任何具体的数据存储无关？

【问题讨论】：

做了例如维基百科没有帮助？ en.wikipedia.org/wiki/Eventual_consistency
@OliCharlesworth：不。也许只有我一个人，但即使读了两遍也完全不清楚。

标签： nosql computer-science data-storage eventual-consistency

【解决方案1】：

最终一致性：

我看了天气预报，得知明天会下雨。
我告诉你明天会下雨。
你的邻居告诉他的妻子明天会是晴天。
你告诉邻居明天要下雨了。

最终，所有的服务器（你、我、你的邻居）都知道了真相（明天会下雨），但与此同时，客户（他的妻子）离开时认为天气会晴，甚至尽管她询问了一台或多台服务器（你和我）是否具有更新的价值。

与严格的一致性/酸合规性相反：

您的银行存款余额为 50 美元。
您存入 100 美元。
从任何地方的任何 ATM 查询您的银行余额为 150 美元。
您的女儿用您的 ATM 卡提取了 40 美元。
从任何地方的任何 ATM 查询您的银行余额为 110 美元。

您的余额在任何时候都不能反映除您账户上所有交易的实际总和之外的任何内容。

原因为什么这么多 NoSQL 系统具有最终一致性，因为几乎所有的 NoSQL 系统都是为分布式而设计的，并且对于完全分布式的系统，存在超线性开销保持严格的一致性（这意味着您只能在事情开始变慢之前进行扩展，当它们出现时，您需要在问题上投入成倍增加的硬件以保持扩展）。

【讨论】：

我不明白。增长是线性的还是指数的？
N个严格一致节点的系统通信开销的增长一般理解为超线性（即超过线性）。可能是指数的，可能是立方的......取决于通信协议等。
好答案。一些后续问题：对服务器的请求可能会给您错误/过时的信息，这不是“不好”吗？人们对此感到满意还是有解决方案？此外，数据最终如何在不同服务器之间复制？如果其中一台服务器出现故障，并且正在跨服务器复制数据，如果该服务器恢复正常，那么它如何使其数据保持最新？
@noblerare 对于不同程度的坏事来说它是“坏事”。如果我的 ATM 余额过期了，那就太糟糕了。如果我的日志数据库没有完全赶上，或者我的 Facebook 提要落后了几秒钟，那就没那么糟糕了。数据复制和持久性机制多种多样，并且取决于特定的平台。对于 Cassandra（例如），编写者可以决定是否要使特定的写入成功，它需要在一个、所有或一个仲裁（大多数）节点上提交。 HBase 采用不同的方法，其中特定节点是每行数据的“主节点”。
其实大部分银行系统都是最终一致的。

【解决方案2】：

最终一致性：

您的数据被复制到多台服务器上
您的客户端可以访问任何服务器来检索数据
有人将一段数据写入其中一个服务器，但尚未复制到其余服务器
客户端使用数据访问服务器，并获取最新的副本
不同的客户端（甚至是同一个客户端）访问不同的服务器（尚未获取新副本的服务器），并获取旧副本

基本上，因为跨多个服务器复制数据需要时间，读取数据的请求可能会发送到带有新副本的服务器，然后再发送到带有旧副本的服务器。术语“最终”意味着最终数据将被复制到所有服务器，因此它们都将拥有最新的副本。

如果您想要低延迟读取，最终一致性是必须的，因为响应服务器必须返回自己的数据副本，并且没有时间咨询其他服务器并就数据内容达成共识。我写了一个blog post 更详细地解释了这一点。

【讨论】：

不错的博文。对于对最终一致性的想法不熟悉的人来说，值得一读。如果重写这个答案以解释博客文章中的更多内容，这个答案会更好。
在您的博客中解释得很好。感谢分享。

【解决方案3】：

最终的一致性更像是一个频谱。一方面你有很强的一致性，另一方面你有最终的一致性。在这之间有一些级别，例如快照、阅读我的写入、有限的陈旧性。 Doug Terry 在his paper on eventual consistency thru baseball 中有一个漂亮的解释 .

在我看来，最终一致性基本上是在每次从数据存储中读取时以随机顺序容忍随机数据。比这更好的是更强大的一致性模型。例如，快照具有陈旧的数据，但如果再次读取将返回相同的数据，因此它是可预测的。有时，应用程序可以容忍在给定时间内过时的数据，超过该时间后它需要一致的数据。

如果您查看一致性的含义，它更多地与一致性或没有偏差有关。因此，在非计算机系统术语中，它可能意味着对意外变化的容忍度。通过ATM可以很好地解释。 ATM 可能离线，因此与核心系统的账户余额不同。但是，可以容忍在一段时间内显示不同的余额。一旦 ATM 上线，它就可以与核心系统同步并反映相同的余额。所以 ATM 可以说是最终一致的。

【讨论】：

【解决方案4】：

当应用程序对一台机器上的数据项进行更改时，该更改必须传播到其他副本。由于更改传播不是即时的，因此在一段时间内，一些副本将具有最新的更改，而其他副本则不会。换句话说，副本将相互不一致。但是，更改最终将传播到所有副本，因此称为“最终一致性”。最终一致性一词只是承认将在一台机器上所做的更改传播到所有其他副本时存在无限延迟。最终一致性在集中式（单副本）系统中没有意义或相关性，因为不需要传播。

来源：http://www.oracle.com/technetwork/products/nosqldb/documentation/consistency-explained-1659908.pdf

【讨论】：

【解决方案5】：

用简单的英语，我们可以说：尽管您的系统可能处于不一致的状态，但目标始终是在每个数据的某个点达到一致性。

【讨论】：

【解决方案6】：

假设您有一个应用程序及其副本。然后您必须向应用程序添加新数据项。

然后应用程序将数据同步到下面显示的其他副本

与此同时，新客户端将从一个尚未更新的副本中获取数据。在这种情况下，他无法获得正确的最新数据。因为同步需要一些时间。在那种情况下，它没有最终一致性

问题是我们如何最终保持一致性？

为此，我们使用中介应用程序来更新/创建/删除数据，并使用直接查询来读取数据。这有助于最终保持一致性

【讨论】：

【解决方案7】：

最终一致性意味着更改需要时间来传播，并且每次操作后数据可能不会处于相同状态，即使对于相同的操作或数据转换也是如此。当人们在与这样的系统交互时不知道自己在做什么时，这可能会导致非常糟糕的事情发生。

在您充分理解此概念之前，请不要实施关键业务文档数据存储。搞砸文档数据存储实现比关系模型更难修复，因为将要搞砸的基本事物根本无法修复，因为修复它所需的事物只是不存在于生态系统中。重构飞行存储的数据也比 RDBMS 的简单 ETL 转换困难得多。

并非所有文档存储都是一样的。现在有些（MongoDB）确实支持某种事务，但迁移数据存储可能与重新实现的费用相当。

警告：开发人员甚至架构师不了解或不了解文档数据存储技术，并且因为害怕丢掉工作而不敢承认这一点，但他们接受过 RDBMS 的经典培训，并且只知道 ACID 系统（多么不同可以吗？）而谁不了解该技术或不花时间学习它，将会错过设计文档数据存储的机会。他们也可能尝试将其用作 RDBMS 或用于缓存等用途。他们会将应该对整个文档进行操作的原子事务分解为“关系”片段，忘记复制和延迟是事情，或者更糟糕的是，将第三方系统拖入“事务”。他们这样做是为了让他们的 RDBMS 可以镜像他们的数据湖，不管它是否会工作，也不需要测试，因为他们知道自己在做什么。然后，当存储在像“订单”这样的单独文档中的复杂对象的“订单项目”比预期的要少，或者根本没有时，他们会感到惊讶。但这不会经常发生，也不会经常发生，所以他们只会向前迈进。他们甚至可能无法解决开发中的问题。然后，他们不会重新设计东西，而是会抛出“延迟”、“重试”和“检查”来伪造一个关系数据模型，这不起作用，但会增加额外的复杂性而无益。但现在为时已晚 - 事情已经部署，现在业务正在运行。最终，整个系统将被淘汰，部门将外包，由其他人维护。它仍然无法正常工作，但它们失败的代价可能比当前的失败要低。

【讨论】：