数据库事务是指数据库执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。
事务拥有以下的4个特性，习惯上被称为ACID特性。
- **原子性（Atomicity）：**事务作为一个整体被执行，包含在其中的对数据库的操作要么全被执行要么不执行。
- 一致性（Consitency）： 执行事务前的状态应该是一致的，且事务执行后也应该是一致的。即中间过渡的状态是对外不可见的。
- 隔离性（Isolation）： 数据库事务之间尽管可能并行发生。但是事务不会感应到这种并发状态，即在事务A与事务B并发时：对与事务A而言，这次事务可能是在事务B还未发生前执行，或者是在事务B发生后执行的。
- 持久性（Durability）： 一个事务成功完成后，它对数据库的改变必须是持久的，即使出现系统故障。
分布式事务及其相关理论：
CAP定理：
Consistency 一致性
Availability 可用性
Partition tolerance 分区容错
这三个指标不能同时做到称为CAP定理。
分区容错 Partition tolerance
大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区
容错的意思是，区间通信可能失败。比如，一台服务器放在中国，另一台服务器放在美
国，这就是两个区，它们之间可能无法通信。
一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们，
剩下的 C 和 A 无法同时做到。
可用性 Availability
Availability 中文叫做"可用性"，意思是只要收到用户的请求，服务器就必须给出回应。
一致性 Consistency
Consistency 中文叫做"一致性"。意思是，写操作之后的读操作，必须返回该值。
一致性和可用性的矛盾
一致性和可用性，为什么不可能同时成立？
答案很简单，因为可能通信失败（即出现分区容错）。
如果保证 G2 的一致性，那么 G1 必须在写操作时，锁定 G2 的读操作和写操作。只有数据同步后，才能重新开放读写。锁定期间，G2 不能读写，没有可用性不。
如果保证 G2 的可用性，那么势必不能锁定 G2，所以一致性不成立。综上所述，G2 无法同时做到一致性和可用性。系统设计时只能选择一个目标。如果追求
一致性，那么无法保证所有节点的可用性；如果追求所有节点的可用性，那就没法做到一致性。
BASE理论：
BASE：全称：Basically Available(基本可用)，Soft state（软状态）,和 Eventually
consistent（最终一致性）三个短语的缩写，来自 ebay 的架构师提出。BASE 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于CAP 定理逐步演化而来的。其核心思想是：
既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务
特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
Basically Available（基本可用）
什么是基本可用呢？假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言：
- 响应时间上的损失：正常情况下的搜索引擎 0.5 秒即返回给用户结果，而基本可用的
搜索引擎可以在 1 秒作用返回结果。
- 功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单，但
是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级
页面。
Soft state（软状态）
什么是软状态呢？相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种
“硬状态”。
软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用
性，即允许系统在多个不同节点的数据副本存在数据延时。
Eventually consistent（最终一致性）
系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，
因此所有客户端对系统的数据访问最终都能够获取到最新的值。
分布式事务解决方案
基于XA协议的两阶段提交
首先我们来简要看下分布式事务处理的XA规范 ：
可知XA规范中分布式事务有AP，RM，TM组成：
- 其中应用程序(Application Program ，简称AP)：AP定义事务边界（定义事务开始和结
束）并访问事务边界内的资源。
- 资源管理器(Resource Manager，简称RM)：Rm管理计算机共享的资源，许多软件都可
以去访问这些资源，资源包含比如数据库、文件系统、打印机服务器等。
- 事务管理器(Transaction Manager ，简称TM)：负责管理全局事务，分配事务唯一标
识，监控事务的执行进度，并负责事务的提交、回滚、失败恢复等。
二阶段协议**?*
- 第一阶段TM要求所有的RM准备提交对应的事务分支，询问RM是否有能力保证成功的提
交事务分支，RM根据自己的情况，如果判断自己进行的工作可以被提交，那就就对工作
内容进行持久化，并给TM回执OK；否者给TM的回执NO。RM在发送了否定答复并回滚
了已经的工作后，就可以丢弃这个事务分支信息了。
- 第二阶段TM根据阶段1各个RM prepare的结果，决定是提交还是回滚事务。如果所有的
RM都prepare成功，那么TM通知所有的RM进行提交；如果有RM prepare回执NO的
话，则TM通知所有RM回滚自己的事务分支。
也就是TM与RM之间是通过两阶段提交协议进行交互的.
- 优点： 尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不
能100%保证强一致）
- 缺点： 实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景。
TCC补偿机制
TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。它分为三个阶段：
Try 阶段主要是对业务系统做检测及资源预留
Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。
Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源 释放。
例如： A要向 B 转账，思路大概是：
我们有一个本地方法，里面依次调用
1、首先在 Try 阶段，要先调用远程接口把 B和 A的钱给冻结起来。
2、在 Confirm 阶段，执行远程调用的转账的操作，转账成功进行解冻。
3、如果第2步执行成功，那么转账成功，如果第二步执行失败，则调用远程冻结接口对应的解
冻方法 (Cancel)。
优点： 相比两阶段提交，可用性比较强
缺点： 数据的一致性要差一些。TCC属于应用层的一种补偿方式，所以需要程序员在实
现的时候多写很多补偿的代码，在一些场景中，一些业务流程可能用TCC不太好定义及处
理。
消息最终一致性
消息最终一致性应该是业界使用最多的，其核心思想是将分布式事务拆分成本地事务进行处理，这种思路是来源于ebay。我们可以从下面的流程图中看出其中的一些细节：
