了解 TCC（Try-Confirm-Cancel）事务模型中的"空回滚"和"悬挂"问题，对构建可靠的分布式系统至关重要。下面这个表格能帮你快速把握它们的核心区别。
| 特性 | 空回滚 | 悬挂 |
|---|---|---|
| 问题本质 | 该回滚的没资源可滚：Cancel 阶段在执行时，发现 Try 阶段并未实际执行，需要无害化处理。 | 时序错乱，资源无法收回：Try 阶段在全局事务已回滚后（Cancel 已执行）才迟到地执行，导致预留的资源被永久占用。 |
| 触发时机 | 在 Try 阶段失败或超时 后，全局事务管理器触发回滚，调用 Cancel 接口时发生。 | 在 Cancel 阶段（空回滚）完成之后，迟到的 Try 请求才到达并执行成功。 |
| 核心矛盾 | 如何让 Cancel 操作识别出 Try 并未执行，从而避免误释放资源。 | 如何阻止迟到的 Try 操作执行，避免其预留的资源无法被后续操作处理。 |
| 直接后果 | 如果未处理，可能会误释放或回滚不属于当前事务的资源，导致数据不一致。 | 预留的资源（如冻结的库存、金额）永远无法被释放或确认，造成资源损耗。 |
⚙️ 深入理解问题机制与解决方案
这两种问题的根源都在于分布式系统中的网络不确定性。解决方案的核心是记录事务状态，让后续操作有据可查。
1. 空回滚：如何让 Cancel 操作"明察秋毫"
空回滚通常是这样发生的：TM（事务管理器）调用某个服务的 Try 方法，但由于网络拥堵或服务短暂宕机，调用失败。TM 因此决定回滚整个全局事务，并向所有参与者（包括刚才调用失败的）发出 Cancel 指令。如果此时这个服务的 Try 请求其实还在网络上"飞"，或者节点重启后恢复了，那么当它的 Cancel 接口被调用时，Try 实际上并未执行 。
解决方案：状态查询，判空而治
关键在于让 Cancel 方法能够判断 Try 是否已执行 。通用的做法是引入一张事务状态控制表 。
-
Try 阶段 ：在执行核心业务逻辑（如冻结资金）之前 ，先向控制表插入一条记录，标记全局事务 ID (
xid) 和状态为TRY（或INIT）。这表示一阶段已尝试执行。 -
Cancel 阶段 ：当 Cancel 被调用时，首先根据当前
xid查询控制表。-
如果记录存在：说明 Try 已执行，这是正常的回滚，继续执行真实的资源释放逻辑。
-
如果记录不存在 ：说明 Try 未执行，即为"空回滚"。此时，Cancel 方法不应执行实际的业务回滚逻辑 ，但可以插入一条状态为
CANCEL的记录（这步对防悬挂很重要），然后直接返回成功 。
-
2. 悬挂：如何拦截"迟到"的 Try 请求
悬挂是空回滚处理不当可能引发的连锁问题。接上例，当 TM 触发回滚并完成空回滚后，那个之前"迷失"的 Try 请求可能又到达了服务端。如果不加检查地执行了它，资源就会被预留。但此时整个全局事务已回滚结束，再也没有人会来调用 Confirm 或 Cancel 处理这些资源，它们就被"悬挂"起来了 。
解决方案：前置检查，拒之门外
解决方案的核心是在 Try 执行前进行检查。
-
Try 阶段 ：在执行核心业务逻辑之前 ，先根据
xid查询事务控制表。-
如果发现已存在一条状态为
CANCEL的记录 ：这说明全局事务已回滚，当前 Try 请求是迟到的，必须拒绝执行，直接抛出异常或返回失败，从而避免资源预留 。 -
如果无记录或记录状态可执行：则正常进行后续操作。
-
🛠️ 最佳实践总结
要可靠地应对这两种异常，需要遵循几个关键原则：
-
使用事务状态表 ：这是所有防护措施的基石。表结构至少包含
xid（全局事务ID，主键）、state（事务状态）、业务主键等 。 -
保证操作的幂等性：无论是 Try、Confirm 还是 Cancel，都可能因为重试机制被多次调用。确保它们执行多次的效果与执行一次相同是关键 。
-
注意操作顺序 ：在 Try 和 Cancel 方法中，先记录状态，再执行业务操作。这个顺序能更好地保证状态判断的准确性。
希望这些解释能帮助你透彻地理解 TCC 中的空回滚和悬挂问题。如果你在具体的业务场景中实现时遇到更细致的问题，我们可以继续探讨。