直接回答：两者都是“最终一致”的分布式事务替代方案。Saga 把全局事务拆成一串本地事务，每步有对应补偿动作，失败时逆序执行补偿回滚——资源无预留，中间态对外可见。TCC 显式分三阶段：Try 预留资源（冻结库存、预授权额度）、Confirm 确认生效、Cancel 释放预留——业务侵入更重但隔离性好，中间态被“预留”隔离。
展开解析：对比维度：隔离性——Saga 的脏读问题：A 服务已提交本地事务而全局尚未完成，其他事务看到中间状态（典型：扣款成功订单未建，用户看到余额少了）；对策是语义锁（订单状态机加“处理中”态禁止其他操作）或可重读设计，TCC 的 Try 阶段把资源冻结天然规避；业务侵入——Saga 只需正常接口加补偿，TCC 要求每个参与者实现三个接口且处理空回滚（Cancel 先于 Try 到达）、悬挂（Try 晚于 Cancel 到达要拒绝）、幂等三大边界；适用——跨服务长事务（出行订票：机票+酒店+租车）用 Saga，资金类强隔离场景（转账、库存秒杀）用 TCC。Saga 的两种编排：编排式（orchestration，中央协调器驱动，状态机清晰可加监控）与协同式（choreography，事件链式触发，去中心但链路不可见易成事故）；生产推荐编排式——分布式事务的最大成本是“事务卡在哪一步”的排查，中央协调器的状态表就是答案。补偿设计铁律：补偿必须幂等（重试必然发生）、补偿本身可能失败要有告警与人工入口、补偿语义是“抵消影响”而非“撤销数据”（已发的通知撤不回，只能发更正）。
追问方向：TCC 的空回滚与悬挂具体如何防御？Saga 编排器自身高可用怎么做？
（约 500 字）