本地事务
对于一组操作， 要么全部成功，要么全部失败。
特点：
ACID 原子性 一致性 隔离性 持久性
原子性：通过undolog日志记录修改之前的数据，如果需要回滚根据undolog回滚
一致性：满足一些预定的规则（外键约束）
隔离性：不同事务之间互不影响 （基于锁实现）
持久性：通过redolog实现，所有更改的数据都会先备份到redolog里面，所有操作完以后提交事务，此时将redolog中的数据刷新到磁盘
为什么要用redolog？
因为它是顺序IO，效率高
spring事务的7种传播行为
@Transactional(propagation=Propagation.REQUIRED)
PROPAGATION_REQUIRED 如果当前没有事务，就新建一个事务，如果已经存在一个事务中，加入到这个事务中。这是最常见的选择。
PROPAGATION_SUPPORTS 支持当前事务，如果当前没有事务，就以非事务方式执行。
PROPAGATION_MANDATORY 使用当前的事务，如果当前没有事务，就抛出异常。
PROPAGATION_REQUIRES_NEW 新建事务，如果当前存在事务，把当前事务挂起。
PROPAGATION_NOT_SUPPORTED 以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
PROPAGATION_NEVER 以非事务方式执行，如果当前存在事务，则抛出异常。
PROPAGATION_NESTED 如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与PROPAGATION_REQUIRED类似的操作。
事务的隔离级别
数据库事务的隔离级别有4种，由低到高分别为Read uncommitted 、Read committed 、Repeatable read 、Serializable 。而且，在事务的并发操作中可能会出现脏读，不可重复读，幻读。
Read uncommitted：读未提交，顾名思义，就是一个事务可以读取另一个未提交事务的数据。会出现脏读、不可重复读、幻读 ( 隔离级别最低，并发性能高 )
Read committed：读提交，顾名思义，就是一个事务要等另一个事务提交后才能读取数据。会出现不可重复读、幻读问题（锁定正在读取的行）
Repeatable read：重复读，就是在开始读取数据（事务开启）时，不再允许修改操作，会出幻读（锁定所读取的所有行）。
SERIALIZABLE ：串行化 可解决脏读 幻读 不可重复读
Mysql的默认隔离级别是Repeatable read，但mysql不会引起幻读问题（它使用了间隙锁）
什么是脏读幻读不可重复读？
出现情况：当我们多个事务同时执行的去操作同一个数据的时候容易导致脏读、不可重复读、幻读的情况产生。
脏读 ：脏读就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问 这个数据，然后使用了这个数据。
不可重复读 ：在一个事务内两次读到的数据是不一样的，称为是不 可重复读。例如，一个编辑人员两次读取同一文档，但在两次读取之间，作者重写了该文档。当编辑人员第二次读取文档时，文档已更改。原始读取不可重复。如果 只有在作者全部完成编写后编辑人员才可以读取文档，则可以避免该问题。
幻读 : 是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。 同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象 发生了幻觉一样。
什么是分布式事务？
在我们单体项目中，由于是使用的是同一个数据库，是同一个数据源，而在分布式环境下我们会存在同一组事务需要去访问不同数据源的情况，也就是跨库的情况，要保证数据的一致性就需要用到我们的分布式事务。
常见的分布式事务的解决方案？
方案:2pc（两段式提交） Tcc seata 可靠消息的最终一致性 最大努力通知
2pc:两阶段提交协议，就是将事务流程分为两个阶段，p( Prepare phase) 准备阶段 c ( commit phase ) 提交阶段
实现方式：
在第一个阶段 准备阶段，事务管理器tm会发送请求去询问各个事务是否准备好，如果都准备好了，进入第二个阶段 提交阶段 提交A B服务的事务。如果在有任何一个服务没准备好，那么事务管理器会通知各个服务进行事务回滚
这个方案会出现的问题:
1.第一阶段，某一个服务很久没有回复事务管理器它的准备情况，会一直等待，造成堵塞
2.第二个阶段，事务管理器在发出提交命令后就宕机了，或者是服务在接收到提交事务命令后也宕机了，这种会导致处理结果不一致的情况。
seata
因为2pc（两段式提交）的方式具有许多问题，我们一般都是采用的seata来处理分布式事务
seata里面有：
TC:事务协调器 管理分支事务和全局状态 发布提交或回滚指令
TM:事务管理器 管理全局事务
RM:资源管理器 管理分支事务
实现原理：
操作开始的时候
1.TM会向TC发送请求注册一个全局事务，并生成一个全局事务XID，然后A服务向TC注册一个分布式事务，并纳入XID管理
2.A服务完成操作后，提交分支事务，并告知TC完成情况，同时会向seata的undolog日志中插入一条数据。然后携带着XID去调用B服务。
3.B服务也会去TC注册一个分布式事务，并纳入XID管理。
4.B服务完成服务后，提交分支事务，并告知TC完成情况，同时会向seata的undolog日志中插入一条数据
5.TC如果收到的所有分支事务的回复都是成功的，那么会发布提交全局事务的指令，并删除seata undolog中的数据
6.TC如果收到的分支事务中有失败的回复，那么会发布回滚指令，根据undolog日志的XID去进行回滚操作。
TCC
try 尝试 confirm 确认 cancle取消 （跟2pc有点相似，也是两个阶段）
实现原理：
try ：锁定资源，会有一个软状态
锁定资源后会告知事务管理器我已经更改状态了，然后根据各个分支事务的状态来确定时进行confirm 还是 cancle;
confirm:如果事务全部成功，更改软状态
cancle:如果事务有失败的，调用各个服务的cancel释放资源
存在问题：
与代码的耦合度较高，同时还要保证各个接口的幂等性问题，导致项目维护困难。
可靠消息最终一致性：
借助消息中间键，进行解耦和异步，但是消息中间键需要支持事务，目前只有rocketmq支持事务消息。
考虑问题：分支事务和发送消息的原子性？
解决：通过发送消息的一个确认回调来解决
消息接收的可靠性？
解决：ack机制
重复消费问题 ？
解决：接口幂等性
1.A服务发送一个half消息到mq，这个half消息是发送到一个特殊的日志中，对于其他消费者而言是不可见的。
2.Mq接收到消息，回调一个消息告知A服务，消息发送成功，A服务可以提交本地事务
3.A提交本地事务，并告知mq本地事务提交的一个状态（回滚/提交）
4.Mq接收到A发送过来的本地事务的状态,如果是提交，此时将half消息放入B的消费队列中，如果是回滚，删除half消息。
5.如果A服务因为网络问题迟迟没有给mq发送本地事务状态，此时mq主动调用A服务提供的事务查询接口 ，获取本地事务的状态，决定half的留存
最大努力通知：
主要用于接入外部平台的情况
外部平台会主动去通知调用服务，如果多次通知后，都没有成功，就不会再去通知调用服务，但是外部平台会提供一个接口，当调用服务恢复后，可以主动去调用这个接口查询。
