最终一致性到底是什么？？

[yeqizhang]

我看到有 V 友发这个问题，但我看到有说数据一致性，这个应该没错？各节点数据的一致性会有延缓，这里强调的是数据相同。

但我以往在网上看到的好像都是讲的分布式事务相关的最终一致性，也就是比如我在一个系统扣款，我要在另外一个系统加钱，解决方案有 2pc，tcc，基于消息队列，补偿，最后还可以人工对账。这里强调的是扣钱加钱这两个动作最终一致，数据最终也是“一致“？

[se77en]

@EmdeBoas 补充一点，Paxos 和 Raft 这种都属于共识协议，一致性（ consistency ）和 共识（ consensus ）并不是同一个概念。

[yeqizhang]

@se77en 又学会一个名词，涨知识了。我觉得你和那个大神谈论的都是比较高深一点的，业务上的分布式事务的一致性是不是有所不一样呢？

[xuanbg]

首先要明确一点：一般业务系统是不可能通过实现分布式事务来保证一致性的。

业务系统不同于数据库，因为对于数据库来说，所有的数据都是抽象的，对于数据的操作也就是 select insert update delete4 个命令。而业务对于业务系统来说是具体的，对业务的操作也并不能抽象为增删改查 4 个接口。所以在业务层面实现 2pc 、3pc 事务是天方夜谭，根本不具备可操作性。

[xuanbg]

@sioncheng A 失败了就没 B 的事了，A 成功了则 B 必须成功。至于 B 在多长时间内成功，肯定是越短越好，但如果这个时间比较长，那也必须接受。反之亦然。

[sioncheng]

@xuanbg 嗯，A 失败了是不需要调用 B， 主要是 A 成功了，B 失败了，整个系统怎么处理。

[22yune]

分布式事务的一致性还是事务的一致性，即业务层面定义的一致性。分布式事务相对与单机事务的难点是：因通信不稳定，参与事务的各个‘进程’如何对状态达成一致。这是个共识问题。
至于 CAP，通常网络 P 很可能发生，无法避免（看到有人说谷歌自建网络非常稳定，不会出现 P ）。所以只能在 CA 上做权衡，C 强一点，A 就弱一点。CA 好像是某个概念（延迟？）的一体两面。建议参考 jepsen.io/consistency，https://www.zhihu.com/people/zhangshuai89/posts

[dzdh]

@sioncheng 最终一致 最粗暴的是共识系统选 leader，以 leader 的结果为准。
首先之所以会出现这样的场景主要是长时间没有获得到其他 S 的应答，那么通常也就是网络问题。以 leader 最终结果为准，其他 S 成功了 leader 失败了那么记为失败。

[xuanbg]

@sioncheng A 成功了，B 就不允许失败，真没办法成功的话，就必须人工介入了。

[sioncheng]

@dzdh 是，etcd,zookeeper,elasticsearch 这类内部有多个节点对外提供 api/service 的分布是系统，是需要有 leader，CAP 场景；我本来想说的是一个大型业务系统里，A 、B 不同子系统（可能还有 C ）完成一个事务的场景，比如一个 web server （ C ）接受到用户的请求，然后需要在 A 、B 两个子系统作出各自不一样的变更的场景。 就是 @xuanbg 说的，一般来说 B 就是成功或者重试或者人工介入，最终完成 A 、B 都变更成功。

[yeqizhang]

@sioncheng 嗯，是有两种场景。一种是分布式数据库之类如 zk 需要 leader 来协调数据一致性的系统，这应该属于 cap 中 C 。另一种是分布式业务系统中一个事务需要在多个节点中处理的最终一致性问题。我之前更多的了解是分布式业务系统的事务场景，所以我看到大家解释最终一致性有两种回答就比较疑惑。
因为我们把它称为事务，这个“一致性”应该和数据库 acid 中的 C 是有类似的含义吧？

[22yune]

我的理解就是#7 说的：最终一致性就是没有一致性。
首先，最终一致性是基于一致性概念衍生的。本来一致是一个原子的概念，一致=没有分歧，没有说部分一致的。
在分布式场景下，一致代价太大。基于 cap，为了 a，只能放弃 c，但业务场景又不能完全放弃。然后就想办法把 c 分级了，就是一致性模型。然后把一致 改名为强一致了。其它的一致性模型都是部分一致的（就是不一致）甚至完全没有一致性保证。其中“如果经过一段时间后要求能访问到更新后的数据，则是最终一致性”（引用自 http://www.blogjava.net/hello-yun/archive/2012/04/16/376744.html ）。
一致性模型中，基于读写及它们的开始时间结束时间，及它们的进程关系这些要素来定义约束，命名一致性模型。非强一致性的模型都只能保证部分一致。无保证的场景就说是最终一致的（可以基于超时额外增加验证补偿机制）。
最终一致性只是部分一致性的一个美化的名字。把不一致说的好像是一致的。不知道是为了忽悠谁。

[yeqizhang]

@22yune 想给你十个赞，哈哈

[VishvaWang]

两个要点
一致：保证不同节点之间的数据是相同的
最终：保证未来的某个时间是一致的，至于这个时间是多久，要看具体的协议，可能一分种之内，一小时之内，下一次数据写入之前，或者，下十次数据写入之前，或者我也不知道啥时候能一致，但是我的算法能保证最终是一致的，恩，最终，你懂了吧！

[coldear]

先说一下我理解的一致性，就是每次写操作后的读操作都能返回最新的数据。

然后就是我理解的为什么会有最终一致性这个东西，其实就是一种妥协。
为了得到高可靠性，需要数据和服务不能只在一个节点。
此时，就产生了一个问题，数据读写的时候需要同步到所有节点，延迟就更高了。
但有些场景又不能忍受那么高的延迟，这时为了得到低延迟，不得不作出妥协，可以容忍写操作后一段时间内系统仍然返回老的数据。

至于怎么实现最终一致性，有各种各样的技术，这就是分布式系统主要讲的内容。

[ericls]

网游

假如每个人的位置是一行记录，每个玩家的客户端是一个副本

如果要强一致性，那只能一个人先走，等这个状态在所有玩家屏幕上反应出来的时候，下一个再走。

[cassyfar]

首先最终一致性里的 C，是指 CAP 里的 C，是 every read gets most recent write

其次最终一致性的 service 不遵循 ACID，大多数时候是遵循 BASE (basic availability, soft state, eventually consistency)

但是最终一致性是一致性，因为最终他一致了，这个还是非常关键的。选择使用最终一致性是一种妥协，不仅包含对于 A 和 P 的优先满足，也是因为写的次数远少于读，和每次写所需要传播的时间不长。

[Aresxue]

@EmdeBoas 我只是大概知道题主想问什么，所以说的比较简单。ACID 是事务的概念，但要区分的话主要是数据库事务以及业务层的事务，数据库事务的 C 是非常清晰的，业务层的事务建立在数据库事务之上，它的 C 就像你说的模糊，但一般情况下业务层事务很少谈到 ACID，ACID 默认情况下其实指的是数据库事务。CAP 的 C 指的就是多个副本数据的一致性, 你说的强一致性包括答主所说的最终一致性只是对数据同步延迟的不同要求, 强一致性适用于实时交易系统，最终一致性多用于离线计算系统, 而像 zk 这种半写集群的一致性要求强度在两者之间。

[EmdeBoas]

@Aresxue
1. ACID 这个概念已经被滥用，有各种解释，就像"一致性"这个词语被滥用一样，这也是造成现在大家认知混乱的原因；建议看看 DDIA 里面作者的观点，我看了是收益良多

2. 从你的回答可以看出你没有读过 CAP 的论文，也不清楚它真正的价值到底在哪里（提到 CAP 就只知道三选二的都是在网上碎片化获取的知识）；关于 C 到底是什么含义：可以参考 https://www.the-paper-trail.org/page/cap-faq/

3. 大家理解的所谓强一致：“写了就能读到最新的”，在工业实践上面是不可能做到的，在有各种延迟的情况下，数据“最新”就是一个不存在的说法； linearizably 就是工业实践能做到的最强一致性，zk 提供了 linearizably 的 sync 接口；你说的多数派叫 Quorum，问题的范畴属于我楼下提到的共识问题（ Paxos 、Raft 、ZAB （ zk 使用的这个）都属于 quorum-based 的共识算法），你可以去了解一下 Quorum 和 2PC 的区别，是做了什么 trade-off，解决什么问题 什么场景来用；现在主流保证多个数据副本之间一致性用的算法也就是上面提到的 Quorum-based 的算法，对于 server 端自己来讲这是共识问题，一致性这个东西的主要观察对象是 client 端

[sunriz]

就是各节点同步有个过程呗，过程中，在不同节点读同个数据可能结果不同，但是这个同步过程完了就都一致了。
最终一致和强一致，说白了就是在所有节点都状态相同之前，允不允许在单个节点读到