在微服务架构中，哪些业务场景会迫使你引入分布式事务？常见的实现方案又有哪些？

回答思路

1. 【回答框架 1】分布式事务适用于跨多个独立数据源或服务的操作需要保持原子性的场景，典型如订单、支付、库存、积分等跨服务业务链路，以及涉及多个数据库或消息队列的写操作。
2. 【回答框架 2】常见方案包括两阶段提交（2PC）及其变体，如XA协议，适合强一致性要求高且并发量低的内部系统，但存在同步阻塞、协调者单点和数据不一致窗口等缺陷。
3. 【回答框架 3】基于消息的最终一致性方案，如本地消息表、事务消息（RocketMQ），通过异步确保消息可靠投递和消费，适用于对实时性要求不高、允许短暂不一致的业务，如订单创建后异步扣减库存。
4. 【回答框架 4】TCC（Try-Confirm-Cancel）方案通过业务层面的补偿操作实现最终一致性，适用于需要预留资源、对一致性要求较高的场景，如账户扣款和冻结，但实现复杂度高，需处理空回滚和悬挂问题。
5. 【回答框架 5】Saga模式将长事务拆分为多个本地事务，通过编排或协同方式执行，失败时执行反向补偿，适用于业务流程长、涉及多个服务的场景，如旅行预订，但缺乏隔离性，需业务层处理并发。
6. 【关键点 1】分布式事务适用于跨服务或跨库的原子写操作，典型如订单、支付、库存链路。
7. 【关键点 2】主流方案包括2PC/XA、TCC、Saga和基于消息的最终一致性，各有适用场景。
8. 【关键点 3】强一致选2PC或TCC，最终一致选消息或Saga，需权衡性能与复杂度。
9. 【关键点 4】分布式事务不保证幂等，需额外设计唯一标识、状态机和去重机制。
10. 【关键点 5】消息方案需处理消息可靠投递和消费，配合重试、死信和幂等表保障最终一致。
11. 【易错点 1】不要将分布式事务等同于业务幂等，需单独设计幂等控制。
12. 【易错点 2】避免在所有跨服务调用中强制使用分布式事务，过度设计会降低性能和可用性。
13. 【易错点 3】TCC和Saga需处理空回滚、悬挂和补偿失败等边界，不能简单套用框架。