分布式事务理论

从理论上讲，分布式事务经常和数据库对比：

数据库 ACID
分布式事务 CAP BASE

数据库ACID分别指：

A atomic 原子性，事务包含的语句要成功则全部成功，要么全部失败
C consistency 事务包含的数据状态是一致的，满足完整性约束
I Isolation 多事务并发互相不干扰
D Durability 一旦事务提交数据就永久保存下来

分布式CAP

Consistency 分布式系统同一时刻保存的数据是一致的
Availability 分布式系统一部分节点不可用后，整体仍然可用
Patiton tolarence 当一部分分区不可用时，必然在C和A之间选择
CAP原则是CAP三者不可能同时满足，只能同时满足其中两者。

分布式BASE

Basic available 基本可用
Soft state
Eventually Consistency 最终一致

而后者就成为柔性事务。

分布式事务设计的方法

参见https://zhuanlan.zhihu.com/p/183753774

2PC 3PC
TCC
本地消息、事务消息、最大努力通知

2PC

可以看出 2PC 和 3PC 是一种强一致性事务，不过还是有数据不一致，阻塞等风险，而且只能用在数据库层面。
2PC是将事务分为两个阶段，首先进行事务准备，除了提交事务，不干什么别的。
然后通过事务协调者，将命令发送给各个数据库，如果全部成功，则返回成功，否则就全部进行回滚。

TCC

而 TCC 是一种补偿性事务思想，适用的范围更广，在业务层面实现，因此对业务的侵入性较大，每一个操作都需要实现对应的三个方法。Try - Confirm - Cancel，和2PC的设计思想一样，中间有个协调者，或者说管理事务生命周期者，用以管理事务的生命周期。
例如说创建某个业务，由若干结点组成，每个结点都需要提供三个方法，如果有一个结点失败，则要全部返回失败，进行回滚。确认和取消就涉及到重试，要重试就涉及到幂等。

重试在应用层面根据返回进行删除，删除时根据情况需要有个间隔，在spring中，使用spring-retrie组件https://blog.csdn.net/qq_29897369/article/details/91347075
幂等，因为重试，需要考虑幂等，有两种方式，一种是在上层由应用来控制，先查询然后再下发，一种是由下层去保证。