事务概览

一、事务

1、事务简介

MySQL 事务主要用于处理操作量大，复杂度高的数据。

• 在 MySQL 中只有使用了Innodb 数据库引擎的数据库或表才支持事务。
• 事务处理可以用来维护数据库的完整性，保证成批的 SQL 语句要么全部执行，要么全部不执行。
• 事务用来管理 insert,update,delete语句

2、事务的条件（ACID）

• 原子性（Atomicity）：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
• 一致性（Consistency）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。
• 隔离性（Isolation）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。
• 持久性（Durability）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

3、隔离级别

• 读未提交（Read uncommitted）:事务未提交，另一个事务就可读到未提交的数据
• 读提交（read committed）：事务提交之后，另一个事务可读取到修改的数据
• 可重复读（repeatable read）：事务开启后，读取到的数据直到事务结束都不会发生变化。
• 串行化（Serializable）：只有一个事务开启，提交后才能开启下一个事务

4、解决的问题

隔离级别	脏读	不可重复读	幻读
读未提交	√	√	√
读提交	×	√	√
可重复读	×	×	√
串行化	×	×	×

二、JDBC事务控制

con.setAutoCommit(false);//关闭事务自动提交
try{
    。。。//业务逻辑
    con.commit();//事务提交
}catch(SQLException e){
    con.rollback();//异常时事务回滚
}finally{
    。。。//资源关闭
}

三、Spring事务控制

1、AOP原理实现

• Before切面方法执行事务开启，在目标方法执行前切入；
• AfterReturnning切面方法执行事务提交，在目标方法无异常执行后切入；
• AfterThrowing切面方法执行事务回滚，在目标方法执行异常时切入；
• After切面方法执行资源关闭，在目标方法执行结束后切入；
• Around切面方法，方法体内调用目标方法，自定义切入点实行的方法

2、声明式事务

• 任何事务在开启和结束后都需要开启事务和关闭资源，提交事务和回滚不会同时出现。出现异常时回滚，

  无异常时提交，

• @Transactional声明式事务

事务属性

1. 传播行为：调用 的子方法是否与调用者共用一个事务控制器
2. 隔离级别：默认与数据库相同
3. 是否只读：查询方法可设置只读
4. 事务超时：指定超时时间，执行时间过长，事务回滚
5. 回滚规则：指定某些异常不用回滚，和只回滚某些异常

四、分布式事务

在微服务架构下，各个微服务独立部署有各自操作的数据库，在某一个大型事务方法执行时会调用其他微服务的方法。造成分布式事务最大的问题是网络延迟原因。

• 在某一个方法调用期间，网络阻塞造成假异常，导致大型事务回滚了而远程的方法却执行成功了
• 大型事务执行期间出现异常，大型事务会回滚但却无法已经调用过的远程的方法回滚

1、CAP理论

​ CAP定理是由加州大学伯克利分校Eric Brewer教授提出来的，他指出WEB服务无法同时满足一下3个属性：

• 一致性(Consistency) ： 客户端知道一系列的操作都会同时发生(生效)
• 可用性(Availability) ： 每个操作都必须以可预期的响应结束
• 分区容错性(Partition tolerance) ： 即使出现单个组件无法可用,操作依然可以完成

2、BASE理论

• BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性
• 所以在发布式系统下首先要保证分区容错性，一致性和可用性只能选其一。（CP）or（AP）

1. Basically Available（基本可用）
2. Soft state（软状态）
3. Eventually consistent（最终一致性）

3、2pc模式

数据库支持的2PC（两阶段提交），又叫XA Transactions。

1. 第一阶段，事务协调器要求每个涉及到的数据库预提交此操作，并反应是否可以提交。
2. 第二阶段，事务协调器要求每个数据库提交事务。

其中某一个事务提交失败，所有事务回滚。

4、柔性事务-TCC事务补偿模式

用户自己编写，try，confirm，cancal逻辑代码

刚性事务：ACID原则，强一致性

柔性事务：BASE原理，最终一致性

一阶段prepare：调用自定义的prepare逻辑，try事务代码块

二阶段commit：调用自定义的commit逻辑，confirm事务提交代码块

二阶段rollback：调用自定义的rollback逻辑，cancal事务补偿代码块

5、柔性事务-最大努力通知方案

按规律进行通知。不保证数据一定能通知成功，但会通过可查询的接口进行操作核对。

• 事务失败时，会发布消息给MQ，间隔几秒发一次，直到消息已被确定收到

6、柔性事务-可靠消息+最终一致性方案

发布消息给延时队列实现定时任务，将要回滚的内容发布给MQ，过了规定时间检查事务是否成功；成功则丢掉消息，未成功执行回滚逻辑。

• 订单服务调用库存服务

  ​ 订单服务创建订单，调用库存服务锁定库存同时会给MQ发布解锁库存的延时消息。若订单创建异常导致回滚，会在数据库销毁订单，但不会运程解锁库存，规定时间后库存服务接收到消息检查库存对应的订单是否存在。存在则保持，不存在则解锁库存。