2PC强一致但微服务中基本不可用，因同步阻塞、协调者单点故障、XA协议兼容性差；TCC业务侵入深但可控性强，适用于资金类核心场景；Saga轻量异步但补偿复杂，适合长流程、可接受最终一致的业务。
分布式事务在微服务里不是“把本地事务搬过去”就行，而是要直面网络、隔离、故障和业务语义的多重撕扯。2PC、TCC、Saga 三者虽都为解决跨服务数据一致，但落地时卡点完全不同——不是技术能不能写出来，而是系统稳不稳、业务扛不扛、团队跟不跟得上。
2PC：强一致的代价太重，微服务里基本走不通
它要求所有参与者严格服从协调者指令，在准备阶段就锁住数据库行或表资源，直到第二阶段结束才释放。这在微服务场景下会引发一连串连锁反应：
- 同步阻塞导致接口响应时间飙升，一个慢节点拖垮整个链路
- 协调者是单点，一旦宕机，所有“半开”事务卡死，人工干预成本高
- 依赖底层支持 XA 协议，而多数云原生数据库（如 TiDB、MongoDB、分库分表中间件）不兼容或已弃用 XA
- 网络分区时可能出现部分提交：协调者发了 commit，但个别参与者没收到，又无可靠重试机制
所以 2PC 实际只适合老系统改造过渡期，或极少数对一致性零容忍、并发量低、数据库同构的内部金融后台。
TCC：业务侵入深，但可控性最强
TCC 把事务控制权交还给业务层，靠 Try（预留）、Confirm（执行）、Cancel（释放）三个接口协同完成。它的挑战不在协议本身，而在工程落地：
立即学习“Java免费学习笔记（深入）”；
- 每个核心服务都要补全三套逻辑，比如“扣款”要写冻结、实扣、解冻，开发量翻两三倍
- Confirm/Cancel 必须幂等，且需处理超时、重复调用、状态不一致等边界——稍有疏漏就会资损
- Try 阶段锁定的是业务资源（如账户可用余额），不是数据库锁，需要额外设计资源管理模块或缓存层
- 跨多服务编排时，事务上下文传递、异常传播、日志追踪难度陡增
典型适用场景是资金类操作，比如支付、退款、授信，因为业务规则清晰、补偿路径明确、容错要求极高。
Saga：流程长、环节多，补偿逻辑容易漏或错
Saga 把一个长事务拆成一系列本地事务，每步成功后触发下一步，失败则按反向顺序执行补偿操作。它轻量、异步、不锁资源，但隐患藏在“补偿”二字里：
- 不是所有操作天然可逆：发短信、推消息、调第三方 API，这些副作用无法真正“回滚”，只能靠通知、撤回、对账等方式弥补
- 补偿事务本身也可能失败，需引入重试 + 死信 + 人工介入机制，整条链路可观测性要求极高
- 各服务间状态不同步时（如订单已发货但库存还没扣减完），Saga 编排器很难判断该走正向还是补偿流
- 缺乏全局事务 ID 统一透传，日志分散、排查困难；尤其在跨团队服务协作时，责任边界模糊
适合订单创建、履约调度、审批流这类步骤明确、补偿定义清晰、能接受短暂最终一致的业务。
本质上，选哪种方案不取决于“哪个更先进”，而要看你的服务治理水位、监控告警能力、业务容错阈值和团队交付节奏。硬推 TCC 给一个刚拆完单体的团队，可能比不用分布式事务还危险。
