原问题：如何理解数据库的内部一致性和外部一致性？
前言
提问者应该是看完了 Google Spanner 的论文，对其中的外部一致性这个词不太了解，所以提出了这个问题。之前看 Spanner 的时候，我也不是很理解外部一致性的具体含义，只是当时并没有钻这个 "牛角尖"。最近突然想把这个问题弄清楚，所以整理了下面几位的回答。第一位作者的回答点明了 ACID的C和CAP的C是不一样的。这里我想说的是，学习计算机的同学应该在不同的课程或书籍中都听过或看到过一致性这个词，但是它们涉及的领域及其含义却是完全不同的。包括分布式领域中的分布式事务的一致性和Paxos 协议解决的一致性，这两者也不是一回事。在理解基础概念的区别后，再看第二位和第三位的回答便可对这个问题有清晰的认识。
作者鸣嵩的回答
ACID的C和CAP的C是不一样的。
数据库教科书里提炼的，ACID的C指的是从业务层面定义约束，例如银行转账场景，转入和转出金额要平衡，又或者外键指向的行必须存在，这个C一方面依赖数据库的保证，例如原子性，也依赖于业务特性和业务层代码实现。
CAP的C是现代分布式系统中大家经常谈到的一致性，其内涵和外延比较丰富。例如，ACID中的I，在分布式系统中如何保证并发Query的隔离级别Isolation，可以认为是一种一致性；多副本间达到一致状态机如Paxos和Raft，也是一种一致性。
作者郁白的回答
最初在数据库文章中见到的"外部一致性"，是Google提出的，它是为了解释在分布式事务中遇到的问题而提出的。这里的一致性描述的是非lock base 的事务引擎下，多个事务之间，数据如何相互可见的性质。
多个并发事务读写的数据（或数据范围），它们能够被数据库感知到冲突（读写之间也算冲突），因此它们在时间线上的顺序由数据库确定，这样的事务间一致性问题可以被认为是内部一致性问题，AnsiSqlIsolation定义的隔离级别就是定义内部一致性的。
而先后执行（执行区间不重叠）的多个事务，它们的在时间线上的顺序由用户确定，数据库无法感知到他们之间的关系，它们之间的一致性问题可以被认为是外部一致性问题。
外部一致性问题在lock base或mvcc实现的单机数据库中并不存在，而在分布式事务中比较常见的不满足外部一致性的情况是"写后读"，即提交成功后不能立即能够被读到；还有一种更复杂的情况，可以称之为 "半写后读"，比如客户端依次执行以下事务：
T1: write A; T2: write B; T3: read A and B;
如果没有全局时钟，那么就可能出现T3读取到最新的B，但是没能读取到最新的A（又或者是能读到最新的 A，却读不到最新的 B）。所以"内部"和"外部"最重要的区别是可见顺序由数据库（内部）确定，还是由用户（外部）确定。
作者欢歌的回答
对外部一致性的认知，主要来自于Spanner的paper。写下自己读paper过程中的理解吧。个人认为，外部一致性描述的不是并发问题，而是在物理时间上先后发生的事务间的关系。外部一致性的目标是：假设事务T1执行完成后，T2才启动，保证让T2看到T1的结果。
这个目标看起来比较好实现，因为T2开始时，T1已经执行完成了。那为什么外部一致性成为Spanner的主要问题？主要来自两个方面：
(1)T1和T2的时间戳可能来自位于不同region的server（server一般是某个Paxos Group 的 Leader）；
(2)不同region间的server之间，时间没法严格同步，即存在误差。（虽然Spanner 用了高大上的硬件以及配套算法来同步时钟，仍然不能绝对保证跨region的服务器的时钟严格同步。因为跨了延迟达到100ms的广域网。）
举个例子来讨论吧:用户A给帐户X存款 10 万（对应事务T1），发生在中国；用户B 查询帐户X的余额（对应事务T2），发生在美国。我们把服务器的误差稍微放大点，比如10 s。
(1)存款事务T1执行时，获取的提交时间戳为t1；
(2)T1执行完成后，A打电话给B，说钱已经存上了；
(3)B去查询（事务T2），T2获取的时间戳可能是t2- 5s; 由于t2-5s < t1，按照时间戳比较，根本查询不到T1的结果（按照物理时间，T1在T2启动前已经完成。二者不是并发的，但执行结果违背了物理时间上事务发生的顺序，即违背了外部一致性）。
原问题链接：/question/56073588
如果觉得《在知乎引发众多分布式数据库大佬争相回答的问题》对你有帮助，请点赞、收藏，并留下你的观点哦！
