专题17：分布式事务面试题（卷王专供 + 史上最全 + 2022面试必备）-V99-from-尼恩Java面试宝典.pdf

分布式事务解决方案：尼恩架构师知识宇宙解析

本文是对尼恩分享的分布式事务解决方案的综合总结，让你快速了解分布式事务的核心概念、解决方案和最佳实践。 你能获得：

• 分布式事务产生的背景和解决方案。
• 各种分布式事务解决方案的优缺点和适用场景。
• 如何在面试中清晰地阐述分布式事务的知识，提升面试成功率。

核心内容：

1. 分布式事务产生的背景：

• 单体应用中不存在事务问题，因为所有业务逻辑都使用同一个数据源和事务管理器。
• 分布式或微服务架构中，每个服务都有自己的数据源和事务管理器，跨服务调用可能导致事务不一致。
  • 详细解释：在分布式系统中，服务A调用服务B，如果A和B都执行成功，但之后出现异常，A的事务可能会回滚，而B的事务不会，从而导致数据不一致。
  • 举例：电商系统中，A服务负责创建订单，B服务负责扣减库存。如果订单创建成功，但扣减库存失败，则可能导致用户下单但没有库存的情况。

2. 常见的分布式事务解决方案：

• 使用消息队列（MQ）：通过消息的可靠传递来保证事务的最终一致性。
• LCN框架：一款事务协调性框架，作为本地事务的协调者，达到事务一致性的效果。
• Seata框架：阿里巴巴开源的分布式事务框架，提供了多种事务模式（AT、TCC、SAGA、XA）。
  • 详细解释：Seata框架通过事务协调器TC、事务管理器TM和资源管理器RM三个组件来协调分布式事务，保证跨多个数据源的数据一致性。
  • 行动建议：选择适合自己业务场景的分布式事务解决方案，并深入了解其原理和使用方法。

3. Seata框架实现原理：

• TM向TC申请全局事务ID，并保存到ThreadLocal中。
• Seata数据源代理修改发起方和参与方的数据源，将前置镜像和后置镜像写入到undo_log表中。
• 发起方获取全局事务ID，并通过改写Feign客户端请求头传入全局事务ID。
• 参与方从请求头中获取全局事务ID并保存到ThreadLocal中，并把该分支注册到SeataServer中。
• 若无异常，发起方通知TC，TC通知所有分支删除undo_log数据；若有异常，则通过undo_log逆向生成SQL语句并执行，然后删除undo_log语句。
  • 详细解释：Seata通过undo_log记录事务操作前后的数据镜像，以便在事务回滚时进行数据恢复，保证事务的原子性。

4. SpringBoot如何整合Seata：

• 引入Seata依赖。
• 将bin下的file文件和registry文件放入到每个项目中并修改，分组名称保持一致。
• 在yml配置文件中配置Seata。
• 引入DataSourceProxy配置文件。
  • 行动建议：参照Seata官方文档，按照步骤配置Seata，并编写测试用例验证其功能。

5. Seata框架和LCN框架的区别：

• LCN采用假关闭，不会立即提交或回滚事务；Seata直接插入数据。
• LCN在发起方宕机时可能发生死锁；Seata可能引起脏读。
  • 详细解释：由于LCN采用假关闭，连接资源没有释放，如果发起方宕机，可能导致连接资源一直被占用，从而引起死锁。

6. CAP理论：

• CAP指的是一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）。
• 在分布式系统中，最多只能同时满足CAP中的两个特性。
  • 详细解释：一致性指所有用户看到的数据是一样的；可用性指总能找到一个可用的数据副本；分区容错性指能够容忍网络中断等故障。
  • 举例：Eureka牺牲了一致性，保证了可用性和分区容错性（AP）；Zookeeper牺牲了可用性，保证了一致性和分区容错性（CP）。

7. BASE理论：

• BASE是基本可用（Basically Available）、软状态（Soft State）和最终一致性（Eventually Consistent）三个短语的缩写。
• BASE理论是对CAP中一致性和可用性权衡的结果，强调最终一致性。
  • 详细解释：BASE理论允许系统中的数据存在中间状态，并认为该中间状态不会影响系统整体可用性，即允许系统不同节点的数据副本之间进行同步的过程存在时延。

8. 分布式事务的类型：

• 刚性事务：满足CAP的CP理论，强调强一致性，如XA协议。
• 柔性事务：满足BASE理论，强调最终一致性，如TCC、Saga、本地事务消息、消息事务。
  • 详细解释：刚性事务要求事务必须满足ACID特性，柔性事务则允许在一定时间内存在数据不一致，但最终要达到一致。

9. TCC事务模型：

• TCC全程是Try、Confirm、Cancel，分别对应准备阶段、提交阶段和取消阶段。
• Try阶段：完成所有业务检查，预留业务资源。
• Confirm阶段：确认执行业务操作，不做任何业务检查，只使用Try阶段预留的业务资源。
• Cancel阶段：取消Try阶段预留的业务资源。
  • 详细解释：TCC是一种补偿型事务，通过业务层的补偿来实现分布式事务的一致性。

10. Saga长事务模型：

• Saga模型将一个分布式事务拆分为多个本地事务，每个本地事务都有相应的执行模块和补偿模块。
• 当Saga事务中任意一个本地事务出错时，可以通过调用相关的补偿方法恢复之前的事务。
  • 详细解释：Saga模型适用于业务流程长、业务流程多，且参与者包含其他公司或遗留系统服务，无法提供TCC模式要求的三个接口的场景。

11. 尼恩揭秘面试技巧：

• 根据场景选择合适的分布式事务解决方案。
• Seata AT模型适用于低吞吐的场景；TCC适用于强一致主要用于核心模块；最终一致方案一般用于边缘模块。
• 分场景回答：数据一致性要求高、吞吐量不高的场景使用Seata AT；数据一致性要求高、吞吐量高的场景使用TCC；数据一致性要求不高的场景使用可靠消息最终一致性方案。
  • 行动建议：针对不同的业务场景，选择合适的分布式事务解决方案，并在面试中清晰地阐述选择的理由。

问答

Q: 什么是分布式事务？

A: 分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单来说，就是由不同的小操作组成，这些小的操作分布在不同的服务节点上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。

Q: 为什么要使用分布式事务？

A: 在分布式系统中，由于数据分布在不同的节点上，本地事务无法保证跨节点的数据一致性。分布式事务可以保证在分布式环境下，多个节点上的数据操作要么全部成功，要么全部失败，从而保证数据的一致性。

Q: 如何选择合适的分布式事务解决方案？

A: 选择合适的分布式事务解决方案需要根据具体的业务场景和需求进行权衡。

• 如果对数据一致性要求非常高，可以选择刚性事务，如XA协议。
• 如果对性能要求较高，且允许在一定时间内存在数据不一致，可以选择柔性事务，如TCC、Saga、本地事务消息、消息事务。
• 如果业务流程较长，且涉及多个服务，可以选择Saga模型。
• 如果对业务代码的侵入性要求较低，可以选择基于消息队列的最终一致性方案。