分布式事务-TCC异常之悬挂

在 TCC（Try - Confirm - Cancel）分布式事务模式中，悬挂是一种需要特别关注的异常情况，以下为你详细介绍 TCC 悬挂的相关内容。

在 TCC 事务模式下，我们通过一个事务协调器来管理多个事务，每个事务先执行 try 方法。当所有事务参与者的 try 方法执行成功，就执行 confirm 方法完成真正逻辑的执行，一旦任意一个事务参与者出现异常，就通过 cancel 接口触发事务回滚，释放 Try 阶段占用的资源。

很显然，这是一个最终一致性的实现方案，因此当 Try 执行成功，就必须确保 Confirm执行成功。当 Try 执行失败，就必须确保 Cancel 实现资源释放。而面试题中提到悬挂问题，指的是 TCC 执行 Try 接口出现网络超时时候，使得 TCC 触发 Cancel 接口回滚，但可能在回滚之后，这个超时的 Try 接口才被真正执行，也就导致 Cancel 接口比 Try 接口先执行。从而造成 Try 接口预留的资源一直无法释放，这种情况就是悬挂。以上就是 TCC 悬挂问题的背景，它确实是每个成熟的高级开发必须要了解的细节。因为有可能会造成比较严重的生产事故。

概念

TCC 悬挂指的是在分布式事务执行过程中，Try 操作由于某些原因（如网络延迟、服务故障等）被延迟处理，而此时事务协调器已经判定该事务执行失败并触发了 Cancel 操作，并且 Cancel 操作正常执行完毕。之后，被延迟的 Try 操作才到达并执行，由于 Cancel 操作已经完成，这个延迟的 Try 操作就没有了对应的 Confirm 或 Cancel 操作与之匹配，导致资源被不合理地锁定或占用，这就是 TCC 悬挂问题。

产生原因

 

• 网络延迟：在分布式系统中，各个服务节点之间通过网络进行通信。如果网络状况不佳，Try 请求可能会在传输过程中出现延迟，使得其到达目标服务的时间晚于事务协调器触发 Cancel 操作的时间。
• 服务过载：目标服务可能由于负载过高，无法及时处理接收到的 Try 请求，导致处理时间过长，从而出现 Try 操作延迟执行的情况。当事务协调器因为长时间未收到 Try 操作的响应而触发 Cancel 操作后，延迟的 Try 操作才开始执行。
• 事务协调器误判：事务协调器可能由于自身的逻辑错误或配置不合理，过早地判定 Try 操作执行失败并触发 Cancel 操作，而实际上 Try 请求还在传输或等待处理，随后延迟的 Try 操作就会造成悬挂问题。

示例场景

假设一个电商系统中有一个订单创建的分布式事务，涉及库存服务和账户服务。当用户下单时，会先调用库存服务的 Try 方法冻结相应的商品库存，再调用账户服务的 Try 方法冻结用户账户中的资金。

• 由于网络延迟，库存服务的 Try 请求在传输过程中被延迟。
• 事务协调器在等待一段时间后，没有收到库存服务的 Try 响应，判定该事务失败，于是触发了库存服务和账户服务的 Cancel 操作。
• 账户服务和库存服务执行 Cancel 操作，释放之前可能已经冻结的资源（虽然库存服务实际上还未执行 Try 操作）。
• 之后，被延迟的库存服务的 Try 请求到达并执行，冻结了商品库存，但此时由于 Cancel 操作已经完成，后续不会再有对应的 Confirm 或 Cancel 操作来处理这个冻结的库存，从而导致库存资源被悬挂。

解决方案

 

• 请求超时控制：在发起 Try 请求时，设置合理的超时时间。如果在规定时间内没有收到响应，要进行相应的处理，避免事务协调器过早地触发 Cancel 操作。同时，对于延迟到达的 Try 请求，可以根据其到达时间进行判断，如果超过了合理的时间范围，可以直接拒绝执行，避免悬挂问题的产生。
• 状态记录与检查：在每个服务中记录事务的执行状态，包括 Try、Confirm 和 Cancel 操作的执行情况。在执行 Try 操作前，先检查当前事务的状态，如果发现 Cancel 操作已经执行过，就不再执行 Try 操作，从而避免悬挂问题。
• 引入补偿机制：当检测到悬挂问题发生时，可以设计相应的补偿机制来释放被不合理占用的资源。例如，在上述电商系统的库存服务中，如果发现出现了悬挂问题，可以手动或自动地释放被冻结的库存，确保资源的正常使用。

此外，实现幂等性也是解决悬挂问题的关键。Try、Confirm和Cancel操作都应设计成幂等的，即无论操作执行多少次，结果都是相同的，这有助于在分布式系统中处理网络重传或操作重试等情况，保证系统的最终一致性。