面试题：微服务架构下熔断与降级对分布式事务的影响及解决方案

Question

在一个基于微服务架构且采用分布式事务（如TCC、Saga等模式）的应用系统中，熔断与降级操作可能会对分布式事务的一致性产生影响。请分析可能出现的影响，并提出具体的解决方案，同时阐述方案在不同业务场景下的可行性与局限性。

Answer 1

可能出现的影响

1. TCC 模式下：
   • 熔断影响：若某个服务熔断，TCC 中的 Try 操作可能部分成功，而后续 Confirm/Cancel 操作因熔断无法执行，导致数据不一致。例如在电商下单场景，库存服务熔断，订单服务 Try 成功创建订单，但库存扣减的 Confirm 操作无法执行，库存与订单状态不一致。
   • 降级影响：降级后执行兜底逻辑，若兜底逻辑与正常业务逻辑不一致，可能破坏 TCC 事务一致性。如支付服务降级为模拟支付成功，而实际未进行真正支付，导致订单状态为已支付但资金未到账。
2. Saga 模式下：
   • 熔断影响：Saga 事务由多个本地事务按顺序执行，若其中一个服务熔断，后续事务无法继续，已执行的事务无法回滚，造成数据不一致。例如在物流配送 Saga 事务中，仓库发货后运输服务熔断，无法完成后续配送确认，货物状态与订单状态不一致。
   • 降级影响：同样，降级的兜底逻辑可能与正常业务逻辑不同，导致 Saga 事务无法按预期完成，破坏一致性。如在订单退款 Saga 中，支付服务降级模拟退款成功，但实际未退款，导致用户账户与订单退款状态不一致。

解决方案

1. TCC 模式：
   • 增加重试机制：对熔断或降级后未执行的 Confirm/Cancel 操作进行重试。可以设置重试次数和重试间隔，在熔断恢复或降级结束后尝试执行。例如，订单服务对库存 Confirm 操作在熔断恢复后重试 3 次，每次间隔 10 秒。
   • 引入补偿事务日志：记录 TCC 操作过程，若出现异常，根据日志进行补偿。如记录库存 Try 操作已扣减库存，若 Confirm 未执行，在一定时间后根据日志执行补偿操作恢复库存。
2. Saga 模式：
   • 设计可重试的 Saga 步骤：每个 Saga 步骤具备重试能力，在服务熔断恢复或降级结束后，从熔断/降级处继续执行。如运输服务熔断恢复后，从运输步骤继续执行物流 Saga。
   • 构建统一的事务协调中心：监控 Saga 事务执行状态，出现熔断或降级时，协调各服务进行恢复或补偿。例如协调中心记录订单退款 Saga 执行到支付退款步骤，若支付服务熔断，待恢复后通知支付服务完成退款。

方案在不同业务场景下的可行性与局限性

1. TCC 模式：
   • 可行性：
     • 重试机制：对于短时间内服务不稳定但最终能恢复的场景可行。如网络抖动导致服务短暂不可用，通过重试可完成 Confirm/Cancel 操作保证一致性。
     • 补偿事务日志：适用于业务操作可补偿的场景，如库存扣减可恢复的电商场景，通过日志能有效保证一致性。
   • 局限性：
     • 重试机制：若服务长时间不可用，重试可能浪费资源且无法解决问题。如服务故障需长时间修复，多次重试无意义。
     • 补偿事务日志：对于一些不可逆转的业务操作难以实现，如已发货商品无法简单恢复库存。
2. Saga 模式：
   • 可行性：
     • 可重试的 Saga 步骤：对于业务流程允许部分步骤重复执行的场景有效，如物流配送可在运输服务恢复后继续配送。
     • 统一事务协调中心：适用于复杂的分布式业务场景，能整体协调事务，保证一致性。如电商全流程的 Saga 事务通过协调中心管理。
   • 局限性：
     • 可重试的 Saga 步骤：若部分步骤执行有副作用，重复执行可能导致问题。如重复发送短信通知用户订单状态。
     • 统一事务协调中心：增加系统复杂度，协调中心自身出现故障可能影响整个事务，且对系统的性能和可靠性要求高。