概述
分布式事务是用来解决跨数据库、跨服务更新数据一致性问题的。那么这里的一致性指的是什么，什么是强一致性，什么是弱一致性，与 CAP 实践中的一致性概念是一样的吗？本文将为您深刻解答相干的问题。
一致性指什么
在数据库的实践中，事务具备大家都相熟的 ACID 个性，别离如下：
- Atomicity（原子性）：一个事务中的所有操作，要么全副实现，要么全副不实现，不会完结在两头某个环节。事务在执行过程中产生谬误，会被复原到事务开始前的状态，就像这个事务素来没有执行过一样。
- Consistency（一致性）：在事务开始之前和事务完结当前，数据库的完整性没有被毁坏。完整性包含外键束缚、利用定义的等束缚不会被毁坏。
- Isolation（隔离性）：数据库容许多个并发事务同时对其数据进行读写和批改的能力，隔离性能够避免多个事务并发执行时因为穿插执行而导致数据的不统一。
- Durability（持久性）：事务处理完结后，对数据的批改就是永恒的，即使系统故障也不会失落。
对于这外面的 C（一致性），咱们以一个十分具体的业务例子，来进行解释。如果咱们正在解决一个转账业务，假如是 A 转给 B 30 元，在本地事务的反对下，咱们的用户看到 A + B 的总金额，在整个转账前后，以及转账过程中，都是放弃不变的。那么这个时候用户认为他看到的数据是统一的，合乎业务束缚的。
当咱们业务变简单，引入多个数据库和大量微服务时，上述本地事务的一致性，仍旧是业务十分关怀。如果一个业务更新操作，跨库或者跨服务时，那么此时业务关怀的一致性问题，就变成了 分布式事务中的一致性问题。
在单机本地事务中，A+ B 的总金额在任何时刻去查（以常见的 ReadCommitted 或 ReadRepeatable 隔离级别），都是不变的，也就是业务束缚始终都放弃的这种一致性，咱们称之为强一致性。
无奈做到强统一
目前在跨库、跨服务的分布式理论利用中，尚未看到有强一致性的计划。
咱们来看看一致性级别最高的 XA 事务，是否是强统一的，咱们以跨行转账（在这里，咱们以跨库更新 AB 来模仿）作为例子来阐明，上面是一个 XA 事务的时序图：
在这个时序图中，咱们在如图所示的工夫点发动查问，那么咱们查到的数据，将是 A +B+30，不等于 A +B，不合乎强统一的要求。
实践上的强一致性
咱们接下来思考，一般 XA 事务不是强统一的，但如果齐全不思考性能因素，有没有可能在实践上做到强统一：
咱们先看看如果咱们把 XA 事务波及的数据库，隔离级别设定到 Serializable，是否能到到强统一的成果呢？咱们来看看后面的时序场景：
这种状况下，查到后果等于 A +B，然而又有另一些场景呈现了问题，如下图所示：
依照图中时序查问的后果是：A+B-30，仍旧是不统一。
深刻思考这个强统一的问题之后，有一种做法能够做到强统一，做法如下：
- 对于查问，也采纳 XA 事务，并且查问数据时，采纳 select for update 的形式，所有数据查完之后，再 xa commit
- 为了防止死锁，须要将波及到的数据库排序，拜访数据都必须要依照雷同的数据库程序来写入和查问
在上述策略下，咱们能够看到，在时序图任何一个工夫点进行查问，取得的后果都是 A +B
- 在 T0 工夫查问，那么批改肯定产生在查问全副实现之后，所以查问失去后果 A +B
- 在 T1，T2，T3 查问，那么查问后果返回肯定全副产生在批改实现之后，所以查问失去后果也是 A +B
很显著这种实践上的强统一，效率极低，所有有数据交加的数据库事务都是串行执行，而且还须要依照特定的程序查问 / 批改数据，因而老本极高，简直无奈利用在生产中。
NewSQL 的强一致性
咱们探讨了跨库、跨微服务的分布式事务是无奈做到强统一的，其实还有一种分布式数据外部的事务，因为事务跨节点了，也被成为分布式事务。这种分布式事务是能够做到强统一的，这种强统一是通过 MVCC 的技术达到的，原理和单机的数据库相似，但简单很多。具体的实现办法能够参考谷歌的 percolator
将来有没有可能借鉴 NewSQL 的这种形式，来实现跨库、跨微服务这类分布式事务的强一致性？实践上是能够的。
- 实现跨服务但不跨库的分布式事务一致性，会绝对简略一些，其中一种形式就是实现 XA 事务中的 TMRESUME 选项（因为最终只有一个 xa commit，不会呈现两个 xa commit 两头的不统一工夫窗口）。
- 实现跨数据库的分布式事务一致性，会艰难很多，因为各个数据库的外部版本机制都不一样，想要协同十分艰难。
弱一致性的分类
既然现有的各种分布式事务计划都无奈做到强统一，那么弱一致性之间是否有差异呢？咱们进行了以下对于一致性强弱的分类：
一致性由强到弱别离是：
XA 事务 > 音讯 >TCC>SAGA
这里的音讯指的是本地音讯表这种类型的分布式事务，对于这四种分布式事务的介绍，参见分布式事务最经典的七种解决方案
他们的分类为：
- 无两头态：数据只有两个状态，事务前和事务后，没有其余第三种状态。XA、音讯这两种都是这种
- 有两头态：数据有两头态，例如 TCC 的 Try，数据状态和事务前事务后都不一样；SAGA 也有两头态，如果一个 SAGA 事务执行正向操作后数据为 W，又回滚了，那么 W 也与事务前事务后的状态不同。
- XA：XA 尽管不是强统一，然而 XA 的一致性是多种分布式事务中，一致性最好的，因为他处于不统一的状态工夫很短，只有一部分分支开始 commit，但还没有全副 commit 的这个工夫窗口，数据是不统一的。因为数据库的 commit 操作耗时，通常是 10ms 内，因而不统一的窗口期很短。
- 音讯：音讯型在第一个操作实现后，在所有操作实现之前，这个工夫窗口是不统一的，继续时长个别比 XA 更久。
- TCC：TCC 的两头态，通常可控，能够自定义。通常状况下，这部分数据不展现给用户，因而一致性比前面的 SAGA 要好。
- SAGA：SAGA 如果产生回滚，而子事务中正向操作批改的数据会被用户看到，可能给用户带来较差的体验，因而一致性是最差的。
咱们这里的分类仅仅从咱们关怀的几个维度进行了演绎，实用于少数场景，但并不一定实用所有状况。在理论的利用中，也可能呈现 TCC 的一致性比音讯更好，例如我在 Try 中执行 xa prepare，Confirm 中执行 xa commit，Cancel 中执行 xa rollback，在这种实现下，TCC 的一致性就跟 XA 一样，一致性其实高于 XA。
CAP 实践中的一致性
咱们这里探讨的一致性是指数据库中的一致性概念，与 CAP 中的一致性不同。
- CAP 中的强一致性是指用户在分布式系统中写完之后，立即去读，如果可能像本地读写那样，读到最新版本，那么是强一致性。
- 分布式事务中的强一致性，是指事务进行的过程中，用户读取的数据始终满足业务束缚，目前在理论利用中的计划，都无奈做到强统一。
上述两者的强一致性在具体的含意上是不同的，但从用户的视角看，也有共通性，即是否像单机零碎一样，不须要关怀分布式带来的新问题。
读者通常会有另一个疑难，那就是分布式事务是一个分布式系统，那么在 CAP 中的一致性如何？
以后 Paxos/Raft 等分布式共识协定曾经在工业畛域有了成熟的实现，当遇见机器故障或网络隔离的状况时，能够做到大概几百个毫秒到几秒内选举出新的 leader，从故障中复原。也就是说 CAP 中，抉择 CP，在 A 下面只有大概几百个毫秒的不可用工夫。
因而对于 NewSQL 或者分布式事务这类数据敏感性利用，个别都抉择 CAP 中的 CP，而就义几百毫秒的 A。因而在这方面，分布式事务是 CAP 中强统一的。例如咱们的 dtm 分布式事务框架，将全局事务进度保留在 CP 的数据库中（云厂商大多提供了 CP 的数据库）
总结
本文详尽的剖析了分布式事务中一致性相干的问题，在确认没有强一致性计划的状况下，剖析了弱一致性分类及实践上可能的强统一计划。
本文许多内容属于独创，如有考虑不周的中央，欢送读者在评论区一起探讨。
- 咱们的公号：分布式事务
- 咱们的我的项目：https://github.com/yedf/dtm
- 欢送应用 dtm，或者通过 dtm 学习实际分布式事务相干常识，欢送 star 反对咱们