简单英语的最终一致性

Question

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

任何人都可以简单解释一般情况下的最终一致性，与任何具体的数据存储无关吗？

Answer 1

最终的一致性：

1. 我看天气预报，明白明天会下雨。
2. 我告诉你明天会下雨。
3. 你的邻居告诉他的妻子，明天会很阳光。
4. 你告诉你的邻居明天会下雨。

最终，所有的服务器（你，我，你的邻居）都知道真相（明天会下雨），但与此同时，客户（他的妻子）认为它会变得晴朗，甚至虽然她问过一个或多个服务器（你和我）有更新的价值。

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

1. 您的银行余额为50美元。
2. 您存入100美元。
3. 您在任何地方从任何ATM查询的银行余额为150美元。
4. 您的女儿用您的ATM卡取款40美元。
5. 您在任何地方从任何ATM查询的银行余额为110美元。

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

原因 为什么这么多NoSQL系统具有最终的一致性，实际上所有这些系统都是为分布式设计的，而且对于完全分布式系统，存在超线性开销保持严格的一致性（意味着你只能在事情开始变慢之前进行扩展，当他们这样做时你需要在问题上投入指数级更多的硬件以保持扩展）。

Answer 2

最终的一致性：

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

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

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

Answer 3

认为你有一个应用程序及其副本。然后，您必须将新数据项添加到应用程序。

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

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

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

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

Answer 4

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

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

Answer 5

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

Answer 6

最终的一致性更像是一个频谱。一方面，您具有很强的一致性，另一方面，您具有最终的一致性。在两者之间有像快照，读我的写作，有限的陈旧等级别。 Doug Terry在his paper on eventual consistency thru baseball中有一个漂亮的解释

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

如果你看一致意义，它更多地与均匀性或缺乏偏差有关。因此，在非计算机系统术语中，它可能意味着容忍意外的变化。通过ATM可以很好地解释它。 ATM可以脱机，因此与核心系统的账户余额不同。但是，对于时间窗口显示不同的余额是可以容忍的。 ATM上线后，它可以与核心系统同步并反映相同的余额。因此可以说ATM最终是一致的。

Answer 7

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

在您完全理解此概念之前，请不要实施关键业务文档数据存储。搞砸文档数据存储实现比关系模型更难解决，因为要搞砸的基本内容根本无法解决，因为修复它所需的内容只是在生态系统中不存在。与使用RDBMS进行简单的ETL转换相比，重构机载存储中的数据也要困难得多。

并非所有文档存储均创建为相等。某些时候（MongoDB）确实支持某种事务，但是迁移数据存储很可能相当于重新实现的费用。

警告：不了解或不了解文档数据存储技术的开发人员，甚至是架构师，他们害怕承认这一点，因为担心失去工作，但是经过RDBMS的经典培训，并且只了解ACID系统（差异有多大？是这样吗？）而谁又不了解这项技术或花时间学习它，就会错过设计文档数据存储的想法。他们还可以尝试将其用作RDBMS或用于诸如缓存之类的事情。他们将应该在整个文档上进行操作的原子交易分解为“关系”部分，而忘记了复制和等待时间就是问题，或者更糟的是，将第三方系统拖入了“交易”中。他们将这样做，以便他们的RDBMS可以镜像其数据湖，而无需考虑它是否会工作，并且无需测试，因为他们知道自己在做什么。然后，当存储在单独的文档（如“订单”）中的复杂对象的“订单项”比预期的少，或者根本没有时，他们将感到惊讶。但这不会经常发生，也不会经常发生，因此他们只会前进。他们甚至可能没有解决开发中的问题。然后，与其重新设计事物，不如将它们放入“延迟”，“重试”和“检查”以伪造一个关系数据模型，该模型虽然行不通，但会增加额外的复杂性而无益。但是现在为时已晚-事情已经部署，现在业务正在此进行。最终，整个系统将被丢弃，部门将被外包，其他人将对其进行维护。它仍然无法正常工作，但是与当前的故障相比，它们的故障损失更低。