SpringCloud面试题, 什么情况下需要使用分布式事务,有哪些方案?

Step 1

Q:: 什么情况下需要使用分布式事务？

A:: 分布式事务在系统中有多个微服务或组件需要共同参与并确保数据一致性时使用。例如，当一个业务操作需要更新多个数据库或微服务时，如果任何一个服务失败或出现错误，需要确保所有服务的数据回滚到一致的状态。这种情况下就需要使用分布式事务来保证系统的完整性和一致性。

Step 2

Q:: 分布式事务有哪些常见的解决方案？

A:: 常见的分布式事务解决方案包括：1) 二阶段提交（2PC），用于较高的一致性需求场景，但牺牲了系统的可用性；2) TCC（Try-Confirm-Cancel），在业务逻辑中实现分布式事务控制，灵活性较高；3) 基于消息的最终一致性，通过事件驱动确保系统最终达到一致状态，如使用消息队列；4) Saga模式，按顺序执行各个事务操作，出错时依赖补偿操作进行回滚。

Step 3

Q:: 什么是二阶段提交（2PC），它的优缺点是什么？

A:: 二阶段提交是一种经典的分布式事务协议，分为准备阶段（prepare）和提交阶段（commit）。在准备阶段，事务协调者询问各个参与者是否可以准备提交，所有参与者都同意后进入提交阶段，执行实际的数据提交。优点是确保了强一致性，缺点是会导致性能下降和潜在的单点故障问题，尤其在网络或服务故障情况下可能导致资源锁定，影响系统可用性。

Step 4

Q:: 什么是TCC（Try-Confirm-Cancel）模式？

A:: TCC是一种分布式事务控制方式，分为三个阶段：Try阶段尝试执行操作并预留资源；Confirm阶段在Try阶段成功后正式提交操作；Cancel阶段在Try阶段失败或其他原因需要回滚时执行资源释放或补偿操作。TCC模式的优点在于灵活性强，可以根据业务需求定制补偿逻辑，缺点是实现复杂度高，需明确设计各个操作的补偿逻辑。

Step 5

Q:: Saga模式如何保证分布式事务的最终一致性？

A:: Saga模式将分布式事务分解为一系列本地事务，通过一系列补偿操作来确保事务的最终一致性。如果某一步操作失败，系统会按照执行顺序逆向执行补偿操作，直至回滚到一致状态。Saga模式适用于长时间运行的事务操作，优点是不会长时间锁定资源，缺点是在补偿操作设计不当时可能导致数据不一致。