分布式事务

事务

指作为单个逻辑工作单元(Service方法)执行的一系列操作（数据库操作。），要么完全地执行，要么完全地不执行.

本地事务

也叫数据库事务或者传统事务

本地事务特点

原子性

不可再分，一个事务就是最小的执行单元

原子性当作有一个东西叫做undolog

何为undolog？

undo log记录了这些回滚需要的信息，当事务执行失败或调用了rollback，导致事务需要回滚，便可以利用undo log中的信息将数据回滚到修改之前的样子

一致性

一致性要求任何写到数据库的数据都必须满足于预先定义的规则（比如余额不能小于0、外键约束等），简单来说就是在任何时间点都不能出现违反一致性要求的状态。

隔离性

持久性

持久性的关键在于一旦“完成提交”（committed），那么数据就不会丢失。undolog实现事务原子性，redolog实现事务的持久性

redolog

Redo Log记录的是新数据的备份。在事务提交前，只要将Redo Log持久化即可，不需要将数据持久化。当系统崩溃时，虽然数据没有持久化，但是Redo Log已经持久化。系统恢复后可以根据Redo Log的内容，将所有数据恢复到最新的状态。

脏读

脏读指的是读到了其他事务未提交的数据，未提交意味着这些数据可能会回滚，也就是可能最终不会存到数据库中，也就是不存在的数据。读到了不一定最终存在的数据，这就是脏读。即就是读到了中间状态的数据，处于存入与未完成存入之间的状态的数据

如何解决脏读

读提交可以解决脏读问题，设置为：set global transaction isolation level read committed; 但是没办法做到重复读也解决不了幻读

不可重复读

可重复读指的是在一个事务内，最开始读到的数据和事务结束前的任意时刻读到的同一批数据都是一致的，那不可重复读就是一个事务多次读取到的数据是不一致的，通常针对数据更新（UPDATE）操作。即：同一个事务中多次使用相同条件读取到的数据是不一样的

如何设置可重复读

set global transaction isolation level repeatable read;可重复读，这也是Mysql默认的事务隔离策略，但是该事务隔离级别没办法解决幻读问题

幻读

事务A 按照一定条件进行数据读取，期间事务B 插入了相同搜索条件的新数据，事务A再次按照原先条件进行读取时，发现了事务B 新插入的数据称为幻读 , 即：事物A两次读取相同条件的数据读到的条数不一样

针对于单数据库的事务我们叫着本地事务/传统事务，在分布式环境中一个请求可能涉及到多个数据库/多个服务的写操作(多数据源)，要保证多数据源的一致性必须用到分布式事务。

常见的分布式事务解决方案

2PC

2PC即两阶段提交协议,是将整个事务流程分为两个阶段,准备阶段( Prepare phase).提交阶段( commit phase ) , 2是指两个阶段, P是指准备阶段, C是指提交阶段。

第一阶段

第一阶段(准备阶段)，事务管理器向事务参与者(资源)们发送准备请求，大家都返回OK状态，那么就进入第二阶段

第二阶段

第二阶段，提交事务，如果在第一阶段有任何一个参与者没有OK，那么事务协调器通知其他所有事务参与者(资源)回滚事务

TCC

TCC, 是基于补偿型事务的AP系统的一种实现, 具有弱一致性补偿理解;按照事先预定的方案去执行，如果失败了就走补偿方案(撤销);下单(try confirm cancel) 扣库存(try confirm cancel)

优点

异步执行效率高

缺点

对应用的侵入性强。业务逻辑的每个分支都需要实现try、confirm、cancel三个操作，应用侵入性较强，改造成本高。实现难度较大。需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。为了满足一致性的要求，confirm和cancel接口必须实现幂等-一个操作多次循环都是一样。

可靠消息最终一致性

可靠消息最终一致性方案是指当事务发起方执行完成本地事务后并发出一条消息,事务参与方(消息消费者)一定能够接收消息并处理事务成功,此方案强调的是只要消息发给事务参与方最终事务要达到一致。此方案是利用消息中间件完成。

解决的问题

本地事务和消息发送原子性

事务参与方接收消息可靠性

最大努力通知

最大努力通知服务表示在不影响主业务的情况下，尽可能地确保数据的一致性。它需要开发人员根据业务来指定通知规则，在满足通知规则的前提下，尽可能的确保数据的一致，以达到最大努力的目的

作用

发起通知方（接口提供方）通过一定的机制最大努力将业务处理结果通知到接收方（接口调用方）