最终一致性的简单解释

Question

最终一致性的简单解释

nosqlcomputer-sciencedata-storageeventual-consistency

172

我经常在不同的关于NoSQL、数据网格等方面的演讲中听到 eventual consistency（最终一致性）这个概念。看起来，在许多来源中， eventual consistency 的定义存在差异（甚至可能取决于具体的数据存储方式）。

有人能简单地解释一下什么是 eventual consistency 吗？不涉及任何具体的数据存储方法，通俗易懂即可。

- Roman

1

难道例如维基百科没有帮助吗？http://en.wikipedia.org/wiki/Eventual_consistency - Oliver Charlesworth

33

@OliCharlesworth说：“不行。也许只是我自己的问题，但即使读了两遍，它仍然非常不清楚。” - Roman

8个回答

129

最终一致性：

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

基本上，由于在多个服务器之间复制数据需要时间，因此读取数据的请求可能会发送到具有新副本的服务器，然后转移到具有旧副本的服务器。 "最终"一词意味着最终数据将被复制到所有服务器上，因此它们都将拥有最新的副本。

如果要进行低延迟读取，则必须具备最终一致性，因为响应服务器必须返回其自己的数据副本，并且没有时间在其他服务器上查询和达成关于数据内容的共识。我撰写了一篇博客文章更详细地解释了这一点。

- Ezra Hoch

3

不错的博客文章，对于对最终一致性概念还不熟悉的人来说值得一读。如果重写以更好地解释博客文章中的内容，这个答案会更好。 - axiopisty

1

你的博客讲解得非常清晰，感谢分享。 - Ataur Rahman Munna

19

假设你有一个应用程序和它的副本。然后你要向应用程序添加新数据项。

应用程序会将数据同步到其他副本，如下图所示

与此同时，新客户端要获取还未更新的某个副本的数据。在这种情况下，他无法获得正确的最新数据，因为同步需要一些时间。此时就没有最终一致性（eventual consistency）了。

问题是如何实现最终一致性？

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

- wthamira

3

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

在充分理解这个概念之前，请不要实现业务关键文档数据存储。因为修复文档数据存储实现的错误比关系型模型要困难得多，因为基本上无法修复被弄糟的东西，因为用于修复它的必要元素在生态系统中不存在。而在飞行存储库中重构数据也比RDBMS的简单ETL转换要困难得多。

并非所有文档存储都是相同的。如今有些文档存储（例如MongoDB）确实支持某种形式的事务处理，但迁移数据存储可能与重新实现的成本相当。

警告：不了解文档数据存储技术，并因害怕失去工作而不敢承认的开发人员甚至架构师，只受过关系型数据库管理系统（RDBMS）经典培训的人，只知道ACID系统（它真的有多大区别吗？），而不知道该技术或花时间学习它，可能会设计糟糕的文档数据存储。他们也可能尝试将其用作RDBMS或用于缓存等事物。他们会把应该操作整个文档的原子事务分解为“关系型”部分，而忘记了复制和延迟是存在的事物，或者更糟糕的是，将第三方系统拖入到“事务”中。他们这样做是为了让他们的RDBMS可以镜像他们的数据湖，而不考虑它是否有效或不测试，因为他们知道自己在做什么。然后当存储在不同文档中的复杂对象（例如“订单”）具有比预期少的“订单项”，甚至可能没有订单项时，他们会感到惊讶。但不会经常发生，或不够频繁，所以他们只会继续前进。他们甚至可能在开发中都没有遇到这个问题。然后，他们将投入“延迟”、“重试”和“检查”来伪造一个关系型数据模型，这是行不通的，但会增加额外的复杂性而没有任何好处。但现在为时已晚——这个东西已经部署了，现在业务正在运行。最终，整个系统将被抛弃，部门将被外包，其他人将维护它。它仍然无法正常工作，但他们可以比当前的失败花费更少的代价。

- ggb667

3

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

- Alice

1

尽管您的系统可能处于不一致的状态，但目标始终是为每个数据达到一致性。简单来说，就是这样。

- Alireza Rahmani Khalili

0

最终一致性更像是一个光谱。在一端，你有强一致性，在另一端，你有最终一致性。在中间，有像快照、读取我的写入、有界陈旧度等级。Doug Terry 在他的论文《通过棒球理解最终一致性》中有一个很好的解释。

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

如果你看一下一致性的含义，它更多地涉及到统一性或缺乏偏差。因此，在非计算机系统术语中，它可能意味着容忍意外变化。这可以通过 ATM 很好地解释。ATM 可能处于离线状态，因此与核心系统的账户余额不同。然而，在一段时间内显示不同的余额是可以容忍的。一旦 ATM 上线，它就可以与核心系统同步，并反映相同的余额。因此，可以说 ATM 最终是一致的。

- Shripad

0

最终一致性保证了系统的一致性，但并非始终如此。存在一个不一致的时间窗口，在这个时间窗口内，某个节点可能没有最新的值，但在查询时仍会返回有效的响应，即使该响应不准确。Cassandra具有环形系统，将您的数据分割成不同的节点：

这些节点中的任何一个都可以作为应用程序的主要接口点。因此，由于这些节点中的任何一个都可以作为您的主要API点，所以没有单一故障点。但是在这里存在一个权衡。因为任何节点都可以是主节点，所以需要在所有这些节点之间复制数据以保持最新状态。因此，所有其他节点都需要始终知道数据的位置，这意味着作为这种架构的权衡，我们具有“最终一致性”。因为数据需要时间才能在系统中的每个节点中传播，所以当数据被写入时，可能需要一点时间才能实际读取刚刚写入的数据。也许数据被写入到一个节点，但是您正在从另一个节点读取它，并且该写入的数据尚未到达该节点。

假设您每个星期日将手机上的照片备份到云端。如果您在周五检查云端上的照片，则不会看到在周一至周五拍摄的照片。您仍然会得到响应，但不是更新后的响应，但如果您在周日晚上检查云端，则会看到所有照片。因此，您的电话和云服务上的数据最终达到一致性。

- Yilmaz

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Chris Shain · Accepted Answer

最终一致性：

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

最终，所有服务器（包括你、我和你的邻居）都知道真相（明天会下雨），但在此期间，客户端（你的邻居的妻子）却认为明天会晴天，尽管她询问时有一个或多个服务器（你和我）具有更实时的值。

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

你的银行余额是50美元。
你存入了100美元。
从任何ATM机查询，你的银行余额为150美元。
你的女儿用你的ATM卡取出40美元。
从任何ATM机查询，你的银行余额为110美元。

在任何时候，你的余额都不能反映出除此时刻之前所有账户上的交易总和以外的任何内容。

为什么许多NoSQL系统具有最终一致性，是因为几乎所有这些系统都设计成分布式的，对于完全分布式系统来说，维护严格的一致性会产生超线性的开销（这意味着在事情开始变慢之前，你只能扩展到某个程度，在出现问题时，你需要投入指数级更多的硬件来保持扩展）。