构建事件驱动的数据网格

第 10 章 最终一致性 最终一致性

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

最终一致性是人们对分布式系统和事件驱动数据产品的主要担忧之一。但对于不同的人来说，最终一致性可能意味着不同的事情。例如，应用程序开发人员使用的数据库可能无法提供读写后的一致性，如大型分布式数据库或使用事件源建立状态时。在事件驱动数据 Mesh 中，我们更关注的是多个消费者系统订阅事件驱动数据产品的影响，以及如何与各个消费者各自以自己的速度读取数据。

长期以来，，有人一直在关注、研究和思考最终一致性问题。帕特-海兰德（Pat Helland）就是这样的人，他撰写了一篇出色的文章，整理了众多思想领袖对这一主题的见解和观点。

由于道格[特里]在1995 年的Bayou 论文中创造了最终一致性这个短语，我对他的观点很感兴趣。当他定义最终一致性时，意思是对于对象集合中的每个对象，每个对象的所有副本最终都将具有相同的值。然后，他说"是啊，我应该叫它最终收敛"

帕特-海兰德

Helland 接着讨论了彼得-阿尔瓦罗（Peter Alvaro）在其 2015 年博士论文"分布式系统的数据中心编程 "中提出的定义：

如果所有信息都已发送完毕，所有副本在存储值集合上达成一致，那么这个系统就是收敛的或 "最终一致 "的。

彼得-阿尔瓦罗

Terry 和 Alvaro 对 "最终一致性 "的定义趋于一致（哈！），将重点放在独立副本最终趋同于同一组存储值上。我们将继续使用 "最终一致性 "这一术语，但请记住，我们真正讨论的是数据的收敛。

不断将事件流具体化的消费者可以轻松地向你提供它的数据存储中确实有哪些数据的信息，但它无法告诉你它没有哪些数据。因为数据存储最终是收敛的，它可能会在被查询时告诉你它没有某个数据，但在下一个时钟周期又会立即接收并处理该数据。不过，消费者确实有能力告诉你它是否已经达到了 给定的偏移量，我们在解决有关收敛的问题时可以利用这一知识。

关于事件驱动世界中最终一致性的许多问题和担忧，都源于人们担心 "坏事 "会因此而发生。它经常被当作一个威胁性的术语，被列在建筑学论文的缺点部分。但它并不一定是个弊端，因为只需注意几件大事。两种独立的消费者服务尚未融合的主要原因有两个：

服务落后

数据产品中的所有数据都是一致的，但有一项服务在数据的消费、处理和存储方面却落后了。

数据产品落后

数据产品内的数据并不一致，但每项服务都能完全更新最新数据。对于事件驱动型数据产品，要么是生产者未能写入数据，要么是事件流不可用。在最坏的情况下，数据产品会严重滞后，以至于可能违反服务水平协议（SLA）。

请注意，这两个选项并不相互排斥。一个或多个消费者服务和一个或多个数据流都缺乏数据是完全可能的。虽然融合最终会带来一致性，但这只是昙花一现，直到我们的服务和数据产品再次出现暂时缺乏数据的情况，需要处理才能赶上。

事实上，最终一致性的影响并不像你想象的那么大，我们将在本章后面介绍一些处理它的好方法。绝大多数情况下，您的事件驱动服务都会与最新事件保持一致，并在同一时间泡沫内有效运行，就像普通的同步服务一样。这也是为什么我认为同步服务会引起很多担忧的原因之一--你永远不知道你的服务何时会开始滞后并转移到它自己的时间泡沫中，如果它开始滞后，如何检测它以及如何处理它。

问题的关键在于，只有当一个独立上下文向另一个独立上下文提出同步问题时，最终一致性才真正开始成为一个问题，而且无法保证它们的内部数据集是同步的。让我们深入了解一下上下文、事件时间和边界与 ...