防止悬挂需业务层用状态表实现状态感知：建tcc_branch_state表记录xid、branch_id、status等，所有操作与状态更新同本地事务；cancel阶段主动检查超时trying记录并补偿；加expire_time字段配合定时巡检强制终态。
防止分布式事务中的网络分区悬挂问题，核心在于让参与者具备“状态感知能力”——即能准确判断当前全局事务是否已进入回滚流程、Try请求是否属于延迟乱序到达。悬挂的本质是：Cancel已执行，Try才后到，导致资源被冻结却无人释放。这不是网络本身能解决的问题，而是必须由业务层主动防御。
用分支事务状态表记录每一步操作
在每个参与者服务本地建一张控制表（如 tcc_branch_state），字段至少包含：xid（全局事务ID）、branch_id、status（TRYING / CONFIRMED / CANCELLED）、created_time。所有 Try/Confirm/Cancel 操作都必须和这张表的更新放在同一个本地事务里。
- Try 执行前先插入一条 status=TRYING 的记录；若插入失败（唯一键冲突或查到已有未完成记录），直接拒绝，避免重复或悬挂
- Cancel 执行时，先查该 xid 对应记录：若无记录，按空回滚处理；若有且 status=TRYING，正常执行并更新为 CANCELLED；若有且 status=CANCELLED，直接幂等返回
- Confirm 同理，只允许从 TRYING 状态跃迁，其他状态抛异常
Cancel 阶段主动检查悬挂并补偿
Cancel 方法不能只做“逆向操作”，还要承担“兜底判断”职责。当发现某 xid 在状态表中存在但未标记为 CANCELLED，且当前时间已远超 Try 的合理执行窗口（比如 5 分钟），就说明 Try 可能已执行但响应丢失，Cancel 却没收到确认——这就是悬挂苗头。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 此时可触发补偿逻辑：例如调用一次“解冻资金”或“释放库存”的幂等接口，确保资源不卡死
- 同时将状态强制置为 CANCELLED，并记录告警日志，供后续人工核对
- 这个判断要加数据库行锁或乐观锁，防止并发 Cancel 重复处理
引入超时清理与定时巡检机制
状态表不是写完就不管。长期滞留的 TRYING 记录大概率就是悬挂事务，必须有自动兜底手段。
- 给状态表加 expire_time 字段，Try 插入时设为当前时间 + 30 分钟
- 用 @Scheduled 每分钟扫描一次 status=TRYING 且 expire_time
- 对这些记录发起异步 Confirm 或 Cancel（取决于业务语义），并标记为“系统强制终态”
- 清理动作本身也要幂等，避免重复触发造成二次问题
不复杂但容易忽略的是：所有这些防护都依赖本地事务的强一致性。如果状态写入数据库成功，但业务操作失败，整个 Try 就得回滚；反过来，业务成功但状态没写进去，也会引发悬挂。所以状态表操作和业务操作必须包在同一个 @Transactional 里，不能拆开。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
