分布式事务方案中，2PC、TCC、Saga、Outbox分别解决的核心一致性问题和隐含代价是什么

这几个方案解决的都是分布式场景下“多个资源之间如何达成业务一致性”的问题，但一致性强度、适用场景和代价不一样。

2PC，也就是两阶段提交，核心解决的是跨多个资源的强一致性提交问题。

它通过协调者把事务拆成两个阶段：

prepare 阶段：所有参与者先预提交，锁定资源，保证自己后续可以提交； commit / rollback 阶段：协调者根据所有参与者的响应决定统一提交或统一回滚。

它的目标是让多个数据库、多个资源管理器尽量像一个本地事务一样，要么都成功，要么都失败。

隐含代价主要是：

性能差 ，因为参与者在 prepare 之后需要持有锁，直到最终提交或回滚； 可用性差 ，协调者故障或者网络异常时，参与者可能长时间阻塞； 对资源管理器要求高 ，通常需要数据库或中间件支持 XA； 不适合高并发长链路业务 ，更适合强一致要求高、链路较短的场景，比如金融核心账务类场景。

TCC，核心解决的是业务层面的强一致或准强一致问题。

TCC 把一个业务操作拆成三个接口：

Try：预留资源，比如冻结余额、锁