在一个电商系统里，用户提交订单后需要同时更新订单服务、库存服务和支付服务的状态。请从分布式事务的角度，给出保证这三个服务数据一致性的设计方案，并说明其适用场景与不足之处。
考察说明
考查候选人对分布式事务模型的理解，以及在电商下单场景下如何权衡一致性、可用性与性能，并设计可落地的方案。
回答思路
- 【回答框架 1】分布式事务的目标是让跨服务的多个写操作要么全部成功，要么全部回滚，但网络分区和故障下无法做到严格ACID，所以通常采用最终一致性。常用方案有两阶段提交（2PC）、TCC、本地消息表、事务消息（如RocketMQ）以及Saga模式。
- 【回答框架 2】2PC通过协调者分两阶段提交，强一致但存在同步阻塞、协调者单点和数据不一致窗口，适合短事务、对一致性要求极高的内部系统，不适合高并发电商。TCC把每个服务操作拆成Try、Confirm、Cancel，灵活但需业务侵入，需处理空回滚和幂等。
- 【回答框架 3】本地消息表：事务性业务与消息写在同一数据库事务中，再异步发送消息，依赖消息表保证可靠性。事务消息（半消息）可解决消息发送与本地事务一致性问题，但需消息中间件支持。Saga将长事务拆成多个本地事务，通过补偿反向操作，最终一致，适合业务链路长、允许短暂不一致的场景。
- 【回答框架 4】在电商下单场景中，可优先采用Saga或事务消息，并设置幂等键、状态机及重试机制。例如，订单创建成功后发消息扣库存，再发消息扣减支付，任何一步失败则执行补偿（如释放库存、退款），同时记录本地事务日志以便对账。
- 【回答框架 5】还需考虑性能与失败恢复：增加事务状态表、定期扫描未完成事务进行补偿，设置超时与人工介入通道。若要求强一致，则可引入Seata AT模式（类似2PC），但会牺牲吞吐，需压测确认。
- 【关键点 1】分布式事务无法同时满足CAP，电商下单通常采用最终一致性。
- 【关键点 2】Saga和事务消息是电商场景推荐方案，2PC/TCC适合短事务或强一致要求。
- 【关键点 3】方案需包含幂等控制、补偿机制和状态机，以应对消息重复与失败。
- 【易错点 1】误将分布式事务等同于保证业务幂等，实际幂等还需唯一标识和状态记录。
- 【易错点 2】忽略2PC的同步阻塞与协调者单点风险，或误以为TCC可完全替代强一致。
- 【易错点 3】补偿逻辑设计不完善，导致数据不一致，需考虑空回滚和悬挂问题。