一、本地事物

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.柔性事物-可靠消息+最终一直性方案（异步确保型）

实现：业务处理服务在业务事物提交前，向实时消息服务请求发送消息，实时消息服务只鸡了消息数据，而不发送。业务处理服务在业务事物提交后，向实时消息服务确认发送。只有在得到确认发送执行后，实时消息服务才会真正的发送。