初识分布式事务原理
事务是指符合ACID特性的操作就是事务，在同一个数据库中，如果要分别对表A和表B进行插入和删除操作，如果其中一个操作执行失败，可以对当前数据库进行回滚，使其回滚到执行操作前的状态，但是现有的系统架构都是基于微服务的，不同服务和操作设计不同的数据库和表，如果插入操作使用的是数据库A，删除操作使用的是数据库B，那么如果想要二者符合事务的特性，要么全部执行成功，要么全部执行失败，如果失败就要进行回滚，但是不同的数据库又不能同时回滚，因此就需要使用分布式事务。
分布式事务 是指：一个业务操作需要跨多个独立的系统（服务、数据库、消息队列等）完成，而我们仍然希望这个操作具有像本地事务一样的特性 —— 要么全部成功，要么全部失败（原子性）。
常见的分布式事务解决方案有：
1. 2PC（Two Phase Commit）（两阶段提交）
2PC是一种最传统的分布式事务协议，用于确保多个数据库、系统之间在事务上达成“一致性或回滚”，它是很多数据库和中间件（如XA和JTA）支持的底层协议。
工作流程涉及一个协调者+多个参与者
1️⃣ 预提交阶段（Prepare Phase）
- 协调者向所有参与者发送“准备提交事务吗？”请求。
- 每个参与者执行本地操作，但不提交，锁住资源。
- 每个参与者回复“准备好了（Yes）”或“失败（No）”。
2️⃣ 提交阶段（Commit Phase）
- 如果所有参与者都回复 Yes，协调者广播 “正式提交”；
→ 所有参与者提交事务，释放资源。
- 如果有任一 No，协调者广播 “回滚”；
→ 所有参与者回滚之前的操作。
两阶段提交通过先让所有参与者先在本地进行执行，但不提交，确保所有参与者执行成功再提交，因此其一致性强，适用于对一致性要求极高的常见，但是缺点是所有参与者在预提交阶段不会进行提交而是锁住资源，会阻塞数据库，并且如果协调者发生“宕机”，会导致所有参与者卡死在等待阶段。
2. TCC（Try-Confirm-Cancel）
TCC 是一种由业务开发者控制的分布式事务模式，强调“预处理 → 确认 → 回滚”的逻辑拆解。
每个参与系统都实现三套接口：
Try: 预留资源（比如冻结库存）Confirm: 真正提交（比如扣减库存）Cancel: 失败回滚（比如解冻库存）
其工作流程不涉及到协调者，而是先让所有参与者进行预处理，执行资源预留，如果所有的参与者都 Try 成功，则进行 Confirm ，否则则进行回滚。
1️⃣ Try 阶段：
- 各参与者尝试执行资源预留，不真正变更资源；
- 保证幂等、挂起（冻结）状态。
2️⃣ Confirm 阶段：
- 所有参与者都 Try 成功后，执行 Confirm，正式提交业务操作；
- 幂等、不可逆。
3️⃣ Cancel 阶段：
- 如果任意参与者 Try 失败，执行 Cancel 补偿；
- 清理预留资源（如解冻、释放）。
3. 事务消息（如RocketMQ事务消息）
通过引入消息中间件的事务消息机制，将发送消息与本地事务进行绑定，来确保分布式事务的正确执行。
工作流程：
1️⃣ 发送“半消息”（Prepared Message）：
- 不立刻投递，标记为暂挂状态。
2️⃣ 执行本地事务：
- 如扣款、更新数据库；
- 返回结果：成功 / 失败。
3️⃣ 通知 MQ 提交或回滚：
- 如果本地事务成功 → MQ 正式投递消息；
- 如果失败 → MQ 丢弃半消息。
4️⃣ 宕机或未知状态：
- MQ 会反查发送方：本地事务执行成功没？（checkTransaction）
值得注意的是，如果本地事务执行成功，消费者会消费到投递的消息，但是如果该消息执行失败，不会导致上游已提交的状态进行回滚，因为该操作的正确有效执行是下游业务需要保证的，不属于上游业务需要考虑的范畴，事务消息只是确保如果本地事务执行失败，则下游业务就不会获取到该条业务消息，只有执行成功的时候才能获取该条业务消息，只有投递的消息是否执行成功，是下游方需要考虑的。