2. 空回滚（Null Rollback）

问题 Cancel 比 Try 先执行。 原因：网络抖动、超时、重试乱序。

此时：

• Try 还没执行
• Cancel 先到了 → 不能真回滚，否则数据错乱

落地方案

• 记录事务状态：未执行 Try 时收到 Cancel，直接返回成功，不做业务回滚
• 用事务日志表记录：tx_id, status, gmt_create

一句话：没做过 Try，Cancel 就空跑，不报错、不回滚。

3. 防悬挂（Anti-Hang / Prevent Suspension）

问题 Cancel 执行完之后，Try 才姗姗来迟。

如果允许 Try 执行：

• 资源被锁定
• 永远不会有 Confirm/Cancel → 事务悬挂，资源泄漏

落地方案

• Cancel 执行后，拒绝后续所有 Try
• 状态机严格控制：
  • 已 cancel → try 直接失败
  • 已 confirm → try 直接失败

一句话：事务一旦结束，绝不允许再执行 Try。

三者关系总结

• 幂等：防重复执行
• 空回滚：防 Cancel 先到导致错误回滚
• 防悬挂：防 Cancel 执行完 Try 又来导致锁死

这三个是 TCC 框架（Seata-TCC、Hmily、TCC-Transaction 等）都内置解决的问题。 如果自己手写 TCC，必须全部实现，否则不能上生产。

注意：本文归作者所有，未经作者允许，不得转载