分布式事务故障隔离核心是防拖垮而非防失败，依赖分层防御、异步解耦与状态可溯：各参与者独立部署、线程池隔离；用补偿+异步替代强一致；熔断降级前置拦截；事务状态独立存储且全链路可观测。
分布式事务参与者之间的故障隔离，核心不是“让事务不失败”，而是“不让一个参与者的故障拖垮整个事务链路或系统”。它依赖的是分层防御+异步解耦+状态可溯的设计逻辑，而不是靠事务本身提供隔离能力——因为XA、TCC、Saga这些方案本身不解决隔离，只解决一致性。
按角色做资源与线程级隔离
每个分布式事务参与者（如订单服务、库存服务、支付服务）应视为独立部署单元：
- 各自使用独立的数据源和连接池，避免共享数据库连接或事务管理器；
- 调用方为每个下游服务配置专属线程池（如Feign + Hystrix/Sentinel 的线程池隔离），防止某个服务响应慢或超时导致调用方线程耗尽；
- 关键路径（如扣库存）与非关键路径（如发通知、写日志）必须拆到不同线程池，避免非核心失败影响主流程。
用补偿与异步替代强一致事务
强事务（如2PC）天然不具备故障隔离能力——一个参与者卡住，整个事务就挂起。真正能隔离故障的是“放弃强同步，改走最终一致”：
- 将长流程事务拆成“核心原子步骤 + 异步补偿步骤”，例如物流单创建中只同步执行“扣库存+生成单号”，其余步骤通过本地消息表+MQ触发；
- 每个异步任务自带重试、死信、人工干预入口，失败不影响上游已提交状态；
- 所有补偿动作需幂等，且记录明确的事务上下文（如全局事务ID、步骤状态），便于定位和人工兜底。
依赖治理与熔断降级前置
故障隔离的前提是“不信任任何下游”，因此要在事务发起前就切断风险扩散路径：
- 对每个远程参与者启用熔断（如Sentinel设置异常比例阈值），一旦失败率超标，自动切断调用，走fallback返回默认结果或排队提示；
- 所有RPC调用必须设超时（connect/read/write），禁止无限等待；
- 关键参与者（如支付网关）应支持多通道切换（主通道+备用通道），故障时自动降级路由，避免单点阻塞整个事务流。
状态存储与可观测性隔离
事务状态本身不能成为故障放大器：
- 全局事务状态（如Seata的TC、Saga的状态机）必须独立部署、独立数据库，不与业务库混用；
- 每个参与者的本地事务日志（如TCC的Try/Confirm/Cancel记录、Saga的Step状态）要落盘可靠，且不依赖其他服务读写；
- 全链路埋点+事务ID透传，确保任一环节出错时，能快速定位是哪个参与者、哪类操作、在哪个状态卡住，而不是靠日志大海捞针。
