第 209 题：分布式事务，2PC与TCC在推荐场景的应用？
题目
分布式事务，2PC与TCC在推荐场景的应用？
完整讲解
一、分布式事务的需求
分布式事务：跨多个服务/库的多步操作，要么全成功要么全回滚，保证一致性。推荐场景如：扣库存 + 写订单 + 发消息 跨多库/服务，需协调一致。
二、2PC（两阶段提交）
- 流程：协调者向各参与者发 prepare；参与者执行本地事务、写 undo/redo，不提交，返回成功/失败。若全成功，协调者发 commit，参与者提交；若有失败，协调者发 abort，参与者回滚。
- 特点：强一致、阻塞式（prepare 后参与者等待 commit/abort）。缺点：协调者单点、参与者阻塞期间占资源；协调者宕机可能导致参与者一直等待，需超时与恢复协议（如 3PC 或人工介入）。
- 适用：数据库内部（如 XA）、对一致性强要求、可接受阻塞与复杂度；推荐业务中若强一致写多库可用 XA，但通常不推荐跨多服务 2PC（耦合与可用性差）。
三、TCC（Try-Confirm-Cancel）
- 流程：Try：各参与者做预留（如冻结库存、占位）；Confirm：全部 Try 成功则执行确认（扣减、落单）；Cancel：任一 Try 失败则执行取消（解冻、释放）。
- 特点：业务层实现两阶段，无全局锁；各阶段需幂等与可补偿。优点：灵活、可跨服务、不长期锁库。缺点：业务侵入大、需实现 Try/Confirm/Cancel 与幂等、空回滚与悬挂等边界要处理。
- 适用：推荐/订单等跨服务场景，可接受最终一致或业务层补偿时，TCC 比 2PC 更常用；配合重试与幂等保证最终一致。
四、推荐场景选型
- 单库多表：本地事务即可。跨库/服务、要强一致：可考虑 2PC/XA，代价高。跨服务、可接受最终一致：TCC 或 Saga（补偿链）、本地消息表/事务消息（先写本地+发消息，消费端幂等），推荐系统常用后两者。
面试要点
- 能说清分布式事务的目标；能描述 2PC 的 prepare/commit-abort 流程及优缺点（强一致、阻塞、单点）。
- 能描述 TCC 的 Try-Confirm-Cancel 及幂等与补偿；能对比 2PC 与 TCC 的适用场景。
- 能给出推荐场景建议：单库本地事务、跨服务 TCC/Saga/消息表；能提及最终一致与幂等。
记忆要点
- 2PC=协调者 prepare→commit/abort，强一致、阻塞、单点；TCC=Try→Confirm/Cancel，业务层两阶段、需幂等与补偿。
- 推荐场景：跨服务常用 TCC、Saga、事务消息；强一致用 2PC 代价高。