java-事务

1.事务的定义

 一般是指要做的或所做的事情.专业术语是这样说的: 就是代码逻辑上的一组操作,这些操作要么全部成功,要么全部失败。使用事务时,要求数据引擎必须是InnoDB引擎。

2.事务的四大特性（ACID）

2-1.事务的原子性( Atomic ) :

一个事务包含多个操作,这些操作要么全部执行,要么全部都不执行.实现事务的原子性,执行回滚操作,在某一个操作失败后,它能够回滚到操作失败之前的状态.

2-2. 事务的一致性 ( Consistency ) :

一致性是指事务使得系统从一个一致的状态转换到另一个一致状态。事务的一致性决定了一个系统设计和实现的复杂度。事务可以不同程度的一致性

2-3.事务的隔离性( Isolation ) :

在一次事务的执行过程中，要求事务锁定的数据操作只存在于该事务中，不影响其他事务的操作，各个事务之间的操作是相互隔离的。只有当前事务提交后，其他事务才能看到当前事务更新的数据。

2-4. 持久性（Durability）:

事务执行完成后，会对数据做持久化存储，即使发生宕机等情况，数据依旧存在。

3.事务的隔离级别

3-1 隔离级别所解决问题(脏读、幻读、不可重复读)

脏读：A事务读取到了B事务尚未提交的数据(尚未提交的数据可能发生回滚)。

幻读：范围读取，在同一个事务内相同的条件(age > 10)多次读取到的数据量不一致。

不可重复读：同一个事务内，相同的条件(age = 10)多次读取的数据结果不一致。

3.2 事务的隔离级别

未提交读(Read Uncommited)：A事务可读取到B事务尚未提交的数据,可导致脏读、幻读、不可重复读。

已提交读(Read commited)：A事务可读取B事务已经提交的数据。可能存在A事务执行过程中B事务已经修改完成，并提交了数据。可导致幻读。不可重复读。

可重复读(Repeated Read)：可重复读指在同一个事务内，锁定当前事务操作的数据，在这个事务还没有结束之前，不允许其他的事务操作这些数据，避免了脏读，不可重复读。但是仍存在幻读的可能。

可串行化(Serializanle)：保证各个事务顺序执行，事务之间互斥，最高的隔离级别，锁表操作。避免了脏读、幻读、不可重复读，但是并发效率低下。

4.事务的传播

4-1 Spring事务传播机制

事务的传播行为是指的就是但一个事务方法被另外一个事务方法调用时,这个事务方法应该如何进行.

例如：methodA事务方法调用methodB事务方法时，methodB是继续在调用者methodA的事务中运行呢，还是为自己开启一个新事务运行，这就是由methodB的事务传播行为决定的。

4-2 事务在Spring中的运作方式

执行过程：开始事务（AOP织入）-@Transaction修饰的方法-处理事务提交或回滚。

Transaction注解可以修饰方法也可以修饰类，修饰类的时候，默认对该类下符合条件的方法均织入事务。

i:开启事务：获取数据库连接，关闭自动提交。

ii:异常回滚：默认情况下只有RuntimeException和Error会进行回滚的，因此回滚前会检查rollBackOn的关键字，查询注解是否做了显示的声明。
 

5.分布式事务

5-1 CAP理论

CAP理论是分布式处理的理论基础，分布式系统在设计时只能在一致性、可用性、分区容忍性之中满足其中的两项,无法同时满足。

一致性(Consistency)：节点A、B、C都存储了用户数据，要求同一时刻三个节点的数据需要保持一致性。

可用性(Availiability)：服务部署A、B、C三个节点，其中一个节点宕机不会影响系统对外提供服务，如果只有一个A节点，当A节点宕机会导致整个系统无法对外提供服务，增加服务节点B、C是为了保证系统的可用性。

分区容忍性(PartitionTolerance)：分区容忍性就是允许系统之间通过网络协同工作，分区容忍性要解决由于网络分区导致的数据不完整及无法访问的问题。

CAP组合方式：CA、CP、AP

CA：放弃分区容忍性，保证数据的可用性和强一致性，关系型数据库按照CA设计。

CP：放弃可用性，加强一致性和分区容忍性，一些强一致性需求要求系统按照CP设计。比如跨行转行，一次转账请求需要等待双方银行系统都完成，整个事务才算完成。需要说明：由于网络问题，该设计可能存在性能问题，导致出现超时等待的情况，如果没有及时处理超时问题，则可能导致整个系统出现阻塞情况。

AP：放弃强一致性，保证数据最终的一致性。加强可用性和分区容忍性，很多NOSQL数据库是按照AP设计的。

总结：在分布式系统中，AP的应用是比较多的，即保证系统的可用性和分区容忍性，牺牲数据的强一致性(写操作后立即读取新数据)，保证数据的最终一致性。比如：订单退款、今日退款成功、明日到账等等。

5-2 分布式事务一致性解决方案

5-2-1 两阶段提交协议2PC

两阶段提交由协调者和参与者组成，共经过两个阶段，三个操作，部分关系型数据库支持两阶段提交协议。

i:第一阶段：准备阶段，协调者通知参与者准备提交订单，参与者开始投票；参与者完成操作后向协调者返回操作结果YES|NO；

ii:提交commit或回滚rollback阶段，协调者根据参与者返回的结果，想参与者发送提交或回滚的指令。

举例订单服务A，需要调用 支付服务B 去支付，支付成功则处理购物订单为待发货状态，否则就需要将购物订单处理为失败状态。 那么看2PC阶段是如何处理的。

上图流程：

i:事务询问 协调者向所有的参与者发送事务预处理请求，称之为Prepare，并开始等待各 参与者 的响应。

ii:执行本地事务 各个 参与者 节点执行本地事务操作,但在执行完成后并不会真正提交数据库本地事务，而是先向 协调者报告说：“我这边可以处理了/我这边不能处理”。

iii:各参与者向协调者反馈事务询问的响应 如果 参与者 成功执行了事务操作,那么就反馈给协调者 Yes 响应,表示事务可以执行,如果没有 参与者 成功执行事务,那么就反馈给协调者 No 响应,表示事务不可以执行。

上图流程：

i：所有的参与者反馈给协调者的信息都是Yes,那么就会执行事务提交协调者 向 所有参与者 节点发出Commit请求。

ii：事务提交 参与者 收到Commit请求之后,就会正式执行本地事务Commit操作,并在完成提交之后释放整个事务执行期间占用的事务资源。

5-2-2 事务补偿TCC

TCC核心思想是："针对每个操作都要注册一个与其对应的确认和补偿（撤销操作）"。

TCC事务补偿是基于2PC实现的业务层事务控制方案，Try\Confirm\Cancel

Try：检查并预留资源，完成事务执行前的检查，并预留事务执行所需要的资源；

Confirm：确定执行业务操作，对Try阶段预留的资源正式执行；

Cancel：确定取消业务操作，对Try阶段预留的资源执行释放；

TCC事务的处理流程与2PC两阶段提交类似，不过2PC通常都是在跨库的DB层面，而TCC本质上就是一个应用层面的2PC，需要通过业务逻辑来实现。这种分布式事务的实现方式的优势在于，可以让应用自己定义数据库操作的粒度，使得降低锁冲突、提高吞吐量成为可能。 不足之处则在于对应用的侵入性非常强，业务逻辑的每个分支都需要实现try、confirm、cancel三个操作。此外，其实现难度也比较大，需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。为了满足一致性的要求，confirm和cancel接口还必须实现幂等。

5-2-3 MQ分布式事务

消息队列实现将一个事务拆分成多个本地事务来完成，并且由消息队列异步协调完成。

如果对数据一致性要求很高，可以采用上面的2PC或者3PC以及TCC方案，如果数据强一致性要求没那么高，可以采用消息中间件（MQ）实现事务最终一致。 在支付系统中，常常使用的分布式事务解决方案就是基于MQ实现的，它对数据强一致性要求没那么高，但要求数据最终一致即可。

例如：向借呗申请借钱，借呗审核通过后支付宝的余额才会增加，但借呗和支付宝有可能不是同一个系统，这时候如何实现事务呢？实现方案如下图：

上图的流程：

i:找花呗借钱

ii:花呗借钱审核通过，同步生成借款单 

iii:借款单生成后，向MQ发送消息，通知支付宝转账

vi:支付宝读取MQ消息，并增加账户余额

上图最复杂的其实是如何保障ii、iii在同一个事务中执行（本地事务和MQ消息发送在同一个事务执行），借款结束后，借呗数据处理就完成了，接下来支付宝才能读到消息，然后执行余额增加，这才完成整个操作。如果中途操作发生异常，例如支付宝余额增加发生问题怎么办？此时需要人工解决，没有特别好的办法，但这种事故概率极低。