分布式事务

事务的含义

事务（Transaction），一般是指要做的或所做的事情，由**事务开始(begin transaction)和事务结束(end transaction)**之间执行的全体操作组成。

简单的讲就是，要么全部被执行，要么就全部失败。

那分布式事务，自然就是运行在分布式系统中的事务，是由多个不同的机器上的事务组合而成的。同上，只有分布式系统中所有事务执行了才能是成功，否则失败。

事务的基本特征ACID：

• 原子性（Atomicity）
  • 一个事务是一个不可分割的工作单位，事务中包括的诸操作要么都做，要么都不做。
• 一致性
  • 指事务执行前和执行后，数据是完整的。
• 隔离性
  • 一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。
• 持久性
  • 也称为永久性，一个事务一旦提交，它对数据库中数据的改变就应该是永久性的保存下来了。

---

分布式事务

分布式事务的目标：解决多个独立事务一致性的问题。
不同微服务，不同库

分布式事务解决方案

1、两阶段提交协议（资源层面）

XA协议，强一致性，遵从ACID。2PC（两阶段提交协议），基于XA/JTA规范

XA/JTA

事务管理器（协调者，TM），资源管理器(各个服务)
1、协调者发送给所有资源开始执行消息
2、各个资源进行数据库操作但不提交事务
3、将执行结果发送给TM
4、TM整合所有资源的返回信息，看是否提交事务
5、通知所有资源是否提交事务
6、各个资源进行事务提交，或者事务回滚
7、将最终信息发送给TM

1~5 投票阶段 6~7提交

问题:
TM单点故障
同步阻塞
数据不一致：TM发送消息时，资源网络异常

无法完美解决事务执行完整性。没有银弹

2、三阶段提交协议

1.CanCommit阶段:和2PC的投票阶段很像
2.PreCommit阶段
3.DoCommit阶段
问题：
如果进入PreCommit后，Coordinator发出的是abort请求，假设只有一个Cohort收到并进行了abort操作，
而其他对于系统状态未知的Cohort会根据3PC选择继续Commit，此时系统状态发生不一致性。

2PC和3PC区别，加了询问，增大成功率。3PC对于Coordinator和Cohort都加了超时机制，2PC只有Coordinator有超时。
3PC主要是在准备阶段和提交阶段之间，插入了预提交阶段。can,pre,do。pre是一个缓冲，保证最后提交阶段之前参与的节点又是一致的

基于消息的最终一致性

采取最终一致性，遵从BASE理论。

BASE：全称是，Basically Avaliable（基本可用），Soft state（软状态），Eventually consistent（最终一致性）三个短语的缩写，来自eBay的架构师提出。

• **Basically Avaliable：**就是在分布式系统环境中，允许牺牲掉部分不影响主流程的功能的不可用，将其降级以确保核心服务的正常可用。
• **Soft state：**就是指在事务中，我们允许系统存在中间状态，且并不影响我们这个系统。就拿数据库的主从复制来说，是完全允许复制的时候有延时的发生的。
• **Eventually consistent：**还是以数据库主从复制为例说，虽然主从复制有小延迟，但是很快最终就数据保持一致了。

分布式事务不可能100%解决，只能提高成功概率。两阶段之间时间，毫秒级别。

补救措施：
定时任务补偿。程序或脚本补偿。
人工介入。

TCC(业务层面分布式事务)

解决方案：TCC（Try、Confirm、Cancel），两阶段补偿型方案。
预先占有资源，确认提交实际操作资源，取消占有=回滚。
如果后两个环节执行一半失败了，记录日志，补偿处理，通知人工。

消息中间件实现

消息队列柔性事务：本地事务+定时任务+消息队列+事件表

问题：
可以保证数据一致性，不能保证时效性

(seata)

TC事务协调者，TM事务管理者（RM）发起事务的RM，RM事务参与者
分支事务：RM,所有参与者得事务