微服务面试几乎必问。面试官要看你能在一致性、可用性、实现成本之间做取舍，不是光背"2PC"。
2PC/XA：强一致但阻塞，协调器挂了就麻烦。互联网公司现在很少用。
TCC（Try-Confirm-Cancel）：业务级2PC，每个操作写三个方法。强一致但代码量巨大，幂等性要求严格。
Saga：一串本地事务，失败时执行补偿动作。扩展性好但只能最终一致，补偿逻辑写起来是业务代码。
本地消息表 / 事务性outbox：业务变更和消息在同一个本地事务里写，另一个进程转发消息。多数系统的务实默认选项。
Seata是Java圈最火的框架——AT模式自动生成undo log做类Saga回滚，TCC模式还是要你手写三方法。
我默认走outbox：一个本地事务里既改订单表又往outbox表插一行，另一个relay进程轮询outbox往Kafka发。下游幂等消费。这样没有2PC、没有协调器、还白送一份审计日志。只有业务真的接受不了最终一致——典型是内部账户之间的钱——我才用TCC，并且预算上乘2-3倍开发时间。2PC/XA新项目我基本不碰，19年见过一个支付系统协调器hang住把整个集群锁死。
幂等键是刚需——每个消费者都得按业务id去重。
跨服务调用特别多？往往是服务边界划错了。合并两个微服务有时候是正解。
即答侠按"2026年面试官到底期待什么"给方案排序——不会让你在2PC上花太多篇幅。
Kafka的exactly-once只在Kafka集群内部。DB写入和Kafka发送仍然是两套系统——outbox靠本地DB事务把这两者原子地桥起来。
自动回滚靠undo log，全局事务期间框架会锁行——高争用场景吞吐会被拖。