一个问题自发地提出：为什么最终要一致性 ？ 酸还不够吗？ 当我们大规模讨论分布式计算时，让我们尝试了解对最终一致性保证的需求，当然涉及数据。
随着Internet和云服务的出现，数据库以及更多的通用数据存储技术发生了根本性的变化：在复制节点上扩展系统 ，而不是在单个节点或很少的节点上扩展计算资源。 需要进行范式转换以适应不断增长的交易量和规模。 CAP定理的主张总结了一种全新的范式引发的新设计技术。
此后，图片试图总结上述概念。 特别是，利用数据库技术描述了交易和规模增长。
现在，让我们来看一些主要概念。
关于分布式系统中的一致性
从广义上讲，分布式系统中副本之间的一致性可以被指定为弱或强 。
弱一致性–容忍副本未对齐
通常，不能保证在任何时候都对齐分布式系统中的副本：由于某种原因，可能会遇到不一致的窗口，并且必须容忍它们。
弱一致性可以进一步分类为“ 最终”和“ 强最终” 。
最终的
如果更新停止，则分布式系统中的副本最终将保持一致。 可能会发生诸如过时的读取或并发的写入之类的冲突，如下所述。
强最终
如果使用无冲突复制数据类型（CRDT） ，则可以实现此目的 。 根据这种保证，不会发生冲突，副本最终将保持一致。
强大的一致性–副本未对齐被视为
在任何时候，副本都是一致的，这意味着：无论在哪个副本上读取状态，结果都将与其他副本读取的结果相同。
关于CAP定理
CAP是一致性 ， 可用性和分区的首字母缩写。 CAP定理指出，在分布式系统中，在大型网络上，不可能满足这三个属性，需要进行权衡。 这种不可能的结果来自不可避免的网络分区：一旦分区，分布式系统的参与者就会变得孤立并且无法通信，这种情况严重影响了复制机制。 在进行网络分区的情况下，如果要实现强一致性，则可能花费很长时间来同步副本，从而严重影响服务的可用性。 另一方面，如果要保留可用性（隔离副本仍根据其自身状态继续服务），则必须将一致性放宽到最终的一致性（一旦网络连接恢复，同步将被恢复）。完成）。
酸碱
ACID是原子性 ， 一致性 ， 隔离性和耐久性的首字母缩写。 它是事务上下文中通常需要的一组属性。 另一方面， BASE是Basicly Available ， Soft state和Eventally的首字母缩写。 它是在分布式系统中经常要尊重的一组属性，这些属性在网络分区的情况下保留可用性，并且更喜欢在网络连接恢复后立即解决冲突。
显然，必须在分布式中重新考虑事务以及事务性：BASE是NoSQL技术提供的保证，能够跨多个区域进行扩展； 相反，ACID是传统SQL数据库提供的保证，它能够在一台机器上进行扩展，但是很难在主动-主动配置中进行扩展（两阶段提交操作所花费的时间严重影响了性能，因此也影响了可伸缩性）。
揭开最终一致性的神秘面纱
最终的一致性并不意味着缺乏交易性，也不缺乏一致性，它仅意味着：整个分布式系统将在不可预测的时间范围内收敛到协调一致的全局状态。 换句话说：在更新之后并且在没有连续更新的情况下，在某个时间点，系统将收敛到一致的状态，但是由于网络应该是异步的并且易于分区，因此没有人可以分辨或预测收敛需要多少时间。
从本地角度（区域中的一个节点或一个节点的法定数量）来看，交易几乎总是传统意义上的预期； 当从全局状态的角度（区域上的复制节点集）观察到一致性时，场景发生了变化：由于许多原因（例如传播延迟，分区等），全局快照可能会在节点之间发现轻微的不一致。
最终一致性体系中的系统会遭受冲突：每次发生未同步数据的并发修改时，都会引发冲突。 可以使用矢量时钟和时间机器的概念来管理此类冲突：每个数据都有一个及时的故事和渐进式版本，解决冲突的最简单方法是找出冲突发生的时间范围，从而撤消更改直到稳定版本并按顺序重新应用更新–这种方法勾勒出了状态机的内在概念。
最终，复制品之间的所有读取将提供相同的输出，这就是重点：不可能先验地确定所有复制品对齐的时间。 在每笔交易都等于金钱的关键业务环境中，这种保证可能是不可接受的； 但是，在Internet和云服务的一般情况下，最终的一致性可以容忍，以支持可用性和对网络分区的抵抗力。 最终一致数据存储的一个很好的例子是DNS，它是当今Internet骨干网中的一种可扩展且完全分布式的目录服务。 DNS的工作方式：数据从中央注册表在递归解析器之间传播，然后在存根解析器之间传播，但是在通往最终客户端服务的路径上，会传递许多缓存级别。
思想
根据建议的图片， SQL是已经使用了很多年的坚如磐石的技术。 现代数据量（主要考虑Internet和云服务）给SQL带来了一些困难：关系数据库尚未设计成可横向扩展的，因此在众多分布式计算机上传播ACID事务需要权衡取舍，这极大地影响了数据库的可用性。整个系统（例如，长时间停下来才能同步对齐副本）。
NoSQL技术诞生于2010年左右，以适应现代设计范例并克服上述SQL限制。 在大多数NoSQL数据库的基础上，都有“最终一致性”的概念，这是为了确保更好的全局可用性而进行的折衷。 这样的技术支持证明了它们在构建大多数在线电子商务服务方面的帮助，甚至仅保证了最终一致性–是的，最终一致性不是邪恶的。
诸如NewSQL之类的新兴技术解决了一致性问题，并试图提出一种现代SQL数据库设计，该数据库能够在地理区域上进行扩展，而无需权衡可用性或一致性。 这些技术支持的首次部署（例如Google Spanner ）证实，可以在不严重影响可用性的情况下在规模上传播类似ACID的交易-使用Paxos / Raft等共识协议，复制延迟保持较低。
答案
结论并回答了最初的问题：最终一致性是超大规模系统设计的成功折衷，每当需要扩展地理区域时，该一致性便广泛应用于该行业。 最新技术提出了对分布式关系数据的更强一致性保证，NewSQL数据库就是这种情况。
无论如何，对于不一定需要强一致性的系统，最终的一致性可以被认为是放心地扩展系统的双赢折衷方案：当然，必须应用思维方式转变和专门的设计才能成功采用这样的可扩展范例。
翻译自: https://www.javacodegeeks.com/2016/02/pills-eventual-consistency.html