在 Dubbo 框架中，分布式事务有哪些实现方式？请简述其原理。
考察说明
考查对 Dubbo 分布式事务解决方案的理解和掌握程度
回答思路
- 【回答框架 1】分布式事务的核心目标是保证跨多个服务或数据源操作的原子性，常见方案包括两阶段提交（2PC）、三阶段提交（3PC）、本地消息表、事务消息、最大努力通知和 TCC 等。Dubbo 本身不直接提供分布式事务能力，需要集成相关组件来支持。
- 【回答框架 2】基于两阶段提交的方案，如 Atomikos 或 Seata 的 AT 模式，通过全局事务协调者（TC）和资源管理器（RM）来协调分支事务，实现强一致性，但存在同步阻塞和协调者单点风险。
- 【回答框架 3】基于消息的最终一致性方案，如 RocketMQ 事务消息或本地消息表，通过消息中间件保证业务操作和消息发送的原子性，通过异步补偿达到最终一致性，适用于对实时性要求不高的场景。
- 【回答框架 4】TCC（Try-Confirm-Cancel）模式通过业务逻辑的显式补偿，将事务拆分为预留资源、确认操作和取消操作三个阶段，适用于对一致性要求高且业务可拆分的场景，但需要业务方实现额外逻辑。
- 【回答框架 5】在 Dubbo 应用中，常用做法是集成 Seata 或使用消息中间件的事务消息功能。具体选型需根据业务对一致性、吞吐量和实现复杂度的要求权衡，并做好异常处理和幂等设计。
- 【关键点 1】Dubbo 本身不内置分布式事务能力，需集成外部组件实现。
- 【关键点 2】常见方案包括 2PC、TCC、本地消息表和事务消息等。
- 【关键点 3】TCC 适合业务可拆分的强一致场景，消息方案适合最终一致性场景。
- 【关键点 4】集成 Seata 或 RocketMQ 是 Dubbo 应用中较普遍的选择。
- 【易错点 1】分布式事务不能无条件保证业务幂等，还需唯一标识和状态记录等机制配合。
- 【易错点 2】避免将单一事务方案泛化为所有场景的最优解。
- 【易错点 3】在性能要求高的场景，2PC 可能成为瓶颈，需权衡一致性级别。