面试题：Java的Spring Boot微服务如何实现分布式事务

原理：
- 第一阶段（投票阶段）：协调者向所有参与者发送事务内容，询问是否可以提交事务，参与者根据自身情况返回“是”或“否”。
- 第二阶段（执行阶段）：若所有参与者都返回“是”，协调者发送提交指令，参与者执行提交操作；若有任何一个参与者返回“否”，协调者发送回滚指令，参与者执行回滚操作。
在Spring Boot微服务中的实现：可以借助数据库自身的XA协议实现，如使用Atomikos等分布式事务管理器，在Spring Boot项目中配置相关依赖和事务管理器，在需要的事务方法上添加@Transactional注解。
优点：原理简单，实现方便，能够保证强一致性。
缺点：单点故障问题，协调者故障会导致整个事务无法推进；同步阻塞问题，在整个事务过程中，参与者处于同步阻塞状态，性能较低；数据不一致风险，如果在第二阶段部分参与者提交成功，部分失败，可能导致数据不一致。

原理：
- 第一阶段（CanCommit阶段）：协调者向参与者发送CanCommit请求，询问是否可以执行事务提交操作，参与者回复“是”或“否”。
- 第二阶段（PreCommit阶段）：若所有参与者都回复“是”，协调者发送PreCommit请求，参与者执行事务操作但不提交，然后回复“准备就绪”；若有参与者回复“否”，协调者发送Abort请求，参与者回滚事务。
- 第三阶段（DoCommit阶段）：协调者根据PreCommit阶段的响应情况，若都准备就绪则发送DoCommit请求，参与者正式提交事务；否则发送Abort请求，参与者回滚事务。
在Spring Boot微服务中的实现：同样可借助分布式事务管理器实现，配置过程与2PC类似，但要注意实现3PC相关逻辑，如增加CanCommit和PreCommit阶段的处理。
优点：相较于2PC，降低了单点故障导致的阻塞风险，因为即使协调者故障，参与者在一定时间后可自行决定提交或回滚；减少了同步阻塞时间，性能有所提升。
缺点：实现复杂，增加了一个阶段，网络开销更大；依然不能完全避免数据不一致问题，比如在DoCommit阶段协调者与参与者网络中断，可能导致数据不一致。

原理：
- Try阶段：尝试执行业务，完成所有业务检查（一致性），预留必须的业务资源。
- Confirm阶段：确认执行业务，真正执行业务，不做任何业务检查，只使用Try阶段预留的业务资源。
- Cancel阶段：取消执行业务，释放Try阶段预留的业务资源。
在Spring Boot微服务中的实现：通过自定义注解和切面来实现TCC事务。定义Try、Confirm、Cancel方法，在切面中根据事务状态调用相应方法。同时结合分布式事务框架，如ByteTCC等，进行事务管理。
优点：性能较好，因为不需要长时间锁定资源；灵活性高，可根据业务需求定制化实现；对应用侵入性相对较小，只需实现特定的Try、Confirm、Cancel方法。
缺点：实现难度较大，需要业务开发人员深入理解并实现Try、Confirm、Cancel逻辑；数据一致性依赖Confirm和Cancel方法的幂等性，如果实现不当，可能导致数据不一致。

星途面试题库