Distributed-transaction
分布式事务的TCC方案：
| 阶段 | 核心动作 | 业务目标 | 隔离性处理 |
|---|---|---|---|
| Try (尝试) | 前置校验和资源预留（冻结）。 | 确保所有参与者都有能力执行，并锁定或冻结未来所需的资源。 | 业务级锁定，而非数据库锁，事务隔离性弱，但效率高。 |
| Confirm (确认) | 正式提交/执行。 | 在 Try 成功的基础上，将预留的资源转为正式消耗或提交。 | 必须保证成功且幂等。 |
| Cancel (取消) | 资源补偿/回滚。 | 释放 Try 阶段预留的资源（如解冻资金、释放库存），将数据恢复到事务前的状态。 | 必须保证成功且幂等。 |
简而言之，就是分布式事务的TCC方案分为try, confirm, cancle三个顺序，尝试根据业务ID来加减量，预冻结（try），若成功则提交事务（confirm）,否则根据冻结的量回滚（cancel）
try阶段来处理逻辑层面的分布式事务。Try 阶段是同步的、可反悔的；Confirm/Cancel 阶段是异步的、不可反悔的。
比如扣减金额（A服务）& 扣减库存（B服务）这样的一个场景，先尝试（预）扣减金额和库存，任何一方发生异常（Try失败），那么就根据冻结的记录来回滚（Cancel），Try成功了则Confirm完成数据的持久化（任何一方失败都需要重试或人工干预至成功）
Confirm 和 Cancel 接口必须具备业务幂等性（比如说订单的状态），以确保在重试机制下，重复调用不会导致重复扣减金额等意外情况。
分布式事务的Saga方案（读作 /ˈsɑːɡə/）：
简而言之，Saga方案就是分为正常流程，补偿流程。在正常流程中任意一个地方发生错误，则基于错误的case来发一个具体的MQ补偿（业务逻辑错误通常回滚，系统逻辑错误通常重试）
正常流程（T）跳转至补偿流程(C)的判断依据：
可重试错误（瞬时系统故障） --> 重试（向前推进）。
不可重试错误（业务逻辑/持久系统故障） --> 启动补偿（向后撤销）。
补偿流程必须按逆序执行，来保证逻辑的正确。
在实践中，架构师的选择倾向如下：
首选 Saga： 对于绝大多数非强金融核心的业务（如订单创建、物流、积分变动），Saga 是更受欢迎的选择，因为它能带来更好的解耦性和吞吐量。
关键场景使用 TCC： 只有当流程中涉及到核心资金账户的扣减，且对数据隔离性要求达到最高级别时，才会考虑使用 TCC。