一、本地事物
1、事物的基本性质
数据库事物的几个特性：原子性、一致性、隔离性、持久性，简称ACID；
原子性：一系列的操作整体不可拆分，要么全成功，要么同时失败。
一致性：数据在事物的前后，业务整体一致。
隔离型：事物之间互相隔离。
持久性：一旦事物成功，数据一定要落盘在数据库。
2.事物隔离级别
读未提交(READ UNCOMMITTED)
会读到未提交事物的数据，此现象称为脏读。
读已提交(READ COMMITTED)
一个数据可以读取到另一个已提交的事物，多次读取会造成不一样的结果，此现象称为不可重复读问题。（Oracle，SQl Server的默认隔离级别）
可重复读(REPEATABLE READ)
MySQL的默认隔离级别，在同一事物里，select的结果是事物开始时时间点的状态，因此同样的select操作读取到的结果是一致的，但是会有幻读现象。
幻读：一个事物按照条件查询数据时，没有对应的数据行，但是插入数据时又发现这行数据已经存在，好像出现了幻影。
序列化(SERIALIZABLE)
串行化顺序执行，MySQL数据库的InnoDB引擎会给读操作隐式加一把读共享锁，从而避免脏读、幻读和不可重复读问题。
3.事物传播行为
PROPAGATION_REQUIRED（默认）:如果当前没有事物，就创建一个新的事务，如果当前存在事物就加入该事物。
PROPAGATION_SUPPORTS:支持当前事物，如果当前存在事物就加入该事物，如果不存在事物，就以非事物之行。
PROPAGATION_MANDATORY:支持当前事物，如果当前存在事物，就加入该事物，如果当前不存在事物，就抛出异常。
PROPAGATION_REQUIRES_NEW:创建新事物，无论当前存不存在事物，都创建新事物。
PROPAGATION_NOT_SUPPORTED:以非事物方式执行操作，如果当前存在事物，就把当前事物挂起。
PROPAGATION_NEVER:以非事物方式执行，如果当前存在事物，则抛出异常。
PROPAGATION_NESTED:如果当前存在事物，则在嵌套事物内执行。如果当前没有事物，则执行与PROPAGATION_REQUIRED类似的操作。
二、分布式事务
1.为什么有分布式事务
在分布式环境下，一个事物可能涉及到多个模块服务之间调用，为了保障事务的原子性，分布式事务是最好的解决方案。
分布式事务是企业集成种的一个技术难点，也是每一个分布式系统中都会涉及到的一个东西，特别是在微服务架构中，无法避免
2.CAP定理与BASE理论
1.CAP定理
一致性（Consistency）：在分布式系统中的所有数据备份，在同一时刻是同样的值。（等同于所有节点访问同一份最新的数据副本）
可用性（Availability）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。
分区容错性（Partition tolerance）：大部分分布式系统都分布在多个子网络。每个自网络叫做一个区。分区容错性的意思是，区间通讯可能失败。
CAP原则指的是，三个要素最多只能同时实现亮点，不可三者兼顾。
一般来说，分区容错无法避免，因此我们可以任认为CAP的P总是成立的，CAP定理告诉我们，剩下的C和A无法同时做到。
2.面临的问题
大多数互联网应用场景，主机多，部署分散，集群规模越来越大，所以节点故障、网络故障是常态，而且要保障服务的高可用，即保证P和A，舍弃C。
3.BASE理论
即使无法做到强一致，但可以采用适当的弱一致性，即最终一致性。
BASE是指
基本可用：指分布式系统中出现故障的时候，允许损失部分可用性。需要注意的是，基本可用绝不等于系统不可用。
--响应时间上的损失：正常情况下搜索引擎需要0.5秒内返回给用户相应的查询结果，但由于故障，查询结果的响应时间增肌到1-2秒。
--功能上的损失：购物网站购物高峰时，为了保护系统的稳定性，部分消费者可能会被引导 到一个降级页面。
软状态：指允许系统存在中间状态，该中间状态不会影响系统整体的可用性。分布式存储中一般一份数据会有多个副本，允许不同副本同步的延迟时就是软状态的体现。
最终一致性：是指系统中所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。
4.强一致性、弱一致性、最终一致性
从客户端角度，多进程并发访问时，更新过的数据在不同进程如果获取的不同策略，决定了不同的一致性。对于关系型数据库，要求更新过的数据能被后续访问看到，这是强一致性。如果能容忍后续的部分或全部访问不到，是弱一致性。如果经过一段时间后要求能访问到最新更新的数据，则是最终一致性。
三、分布式事务解决方案
1.2pc模式
数据库支持的2PC（二阶提交），又叫XA Transactions.MySQL5.5版本后支持。
XA是一个两阶段提交协议，该协议氛围以下两个阶段。
第一阶段：事务协调器要求每个涉及到事务的数据库预提交此操作，并反映是否可以提交。
第二极端：事务协调器要求每个数据库提交数据。
如果有任何一个数据库否决此次提交，那么所有数据库都会被要求回滚他们在此事物中的那部分信息
2.柔性事物-TCC事物补偿型方案
刚性事物：运训ACID原则，强一致性。
柔性事物：遵循BASE理论，最终一致性；
与刚性事物不同，柔性事物允许一定时间内，不同节点的数据不一致，但要求最终一致。
- 一阶段 prepare 行为：调用 自定义 的 prepare 逻辑。
- 二阶段 commit 行为：调用 自定义 的 commit 逻辑。
- 二阶段 rollback 行为：调用 自定义 的 rollback 逻辑。
所谓 TCC 模式，是指支持把 自定义 的分支事务纳入到全局事务的管理中。
3.柔性事物-最大努力通知型方案
按照规律进行通知，不保证数据一定能够通知成功。但会提供可查询操作接口进行核对。这种方案是结合MQ进行实现，例如：通过MQ发送http请求，设置最大通知次数。达到通知次数后即不在通知。
4.柔性事物-可靠消息+最终一直性方案（异步确保型）
实现：业务处理服务在业务事物提交前，向实时消息服务请求发送消息，实时消息服务只鸡了消息数据，而不发送。业务处理服务在业务事物提交后，向实时消息服务确认发送。只有在得到确认发送执行后，实时消息服务才会真正的发送。
