分布式事务方案包括：1. 2PC，强一致但性能差，需JTA+Atomikos支持；2. TCC，高性能补偿事务，适用于电商场景；3. 消息队列+本地事务表，通过RocketMQ实现最终一致；4. Saga模式，拆分长事务，适合复杂流程。实际多用TCC和消息事务。
在Java后端开发中，实现分布式事务的核心目标是保证多个服务或数据库之间操作的一致性和原子性。由于传统本地事务（如Spring的@Transactional）无法跨服务生效，必须引入分布式事务解决方案。以下是几种主流且实用的实现方式：
1. 两阶段提交（2PC）——强一致性方案
2PC是一种经典的分布式事务协议，分为“准备”和“提交”两个阶段，由协调者统一控制所有参与者的提交或回滚。
适用场景：对数据一致性要求极高，且服务间能接受一定性能损耗。
- Java中可通过JTA（Java Transaction API）+ JTS（Java Transaction Service）实现，结合Atomikos、Bitronix等事务管理器。
- 例如：多个数据库操作需要同时提交，使用Atomikos配置多数据源事务管理器即可支持XA协议。
缺点：同步阻塞、单点故障风险高、性能较差，实际生产中较少直接使用。
立即学习“Java免费学习笔记（深入）”；
2. TCC（Try-Confirm-Cancel）——补偿型事务
TCC通过定义三个操作阶段来实现最终一致性：
- Try：资源预留（冻结库存、扣减额度）
- Confirm：确认执行（正式扣减），幂等操作
- Cancel：取消预留（释放冻结资源），幂等操作
在Java中可基于Spring Cloud或Dubbo服务调用，手动实现TCC接口，或使用开源框架如ByteTCC、TCC-Transaction。
优点：性能好、无长期锁，适合高并发场景（如电商下单）。
挑战：业务侵入性强，需开发者自行设计补偿逻辑。
3. 消息队列 + 本地事务表 —— 最终一致性
利用消息中间件（如RocketMQ、Kafka）保证事务消息的可靠投递。
典型流程：
- 先执行本地数据库操作，同时将消息写入“本地事务表”。
- 确认本地事务提交后，异步发送消息到MQ。
- 下游服务监听消息并执行对应操作，确保最终一致。
RocketMQ支持“事务消息”，通过half message机制保障消息不丢失，Java中集成简单，适合订单创建后通知库存、积分等场景。
4. Saga模式 —— 长事务解决方案
Saga将一个大事务拆分为多个可补偿的子事务，每个子事务都有对应的补偿动作。
两种实现方式：
- 编排式（Choreography）：各服务通过事件驱动协作，适合流程简单场景。
- 协调式（Orchestration）：由一个协调器控制事务流程，逻辑清晰，推荐使用。
Java中可用Camunda、SimpleFlow等流程引擎实现，适用于跨多个微服务的复杂业务流程（如订票+支付+出票）。
基本上就这些。选择哪种方案取决于你的业务需求：追求强一致性可考虑2PC（但慎用），高性能和最终一致性推荐TCC或消息队列方案，复杂流程则用Saga。实际项目中，TCC和消息事务最为常见。
