本文目录导读：
分布式事务面试题全解析
分布式事务的基本概念
1、定义
- 分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上，就是在分布式环境下运行的事务，它涉及到多个独立的数据源或服务的操作，这些操作需要保证原子性、一致性、隔离性和持久性（ACID）特性。
图片来源于网络，如有侵权联系删除
- 在一个电商系统中，下单操作可能涉及到库存系统扣减库存、订单系统创建订单、支付系统处理支付等多个子系统的操作，这些操作分布在不同的服务器上，并且需要作为一个整体来保证数据的正确性，这就是一个分布式事务场景。
2、与传统事务的区别
- 传统事务主要是在单个数据库系统中进行操作，数据库自身的事务管理机制（如MySQL的InnoDB引擎的事务处理）能够很好地保证ACID特性，而分布式事务跨越多个不同的数据源或服务，这些数据源可能使用不同的数据库管理系统，甚至包括非数据库的服务（如消息队列）。
- 传统事务的锁机制、日志管理等都是在一个集中式的环境下进行的，而分布式事务需要考虑网络延迟、节点故障等分布式环境下特有的问题，在传统事务中，数据库的并发控制通过锁来实现相对简单高效，但在分布式事务中，要协调多个节点上的并发操作就复杂得多。
分布式事务的实现模式
1、两阶段提交（2PC）
原理
- 2PC协议中有一个协调者（Coordinator）和多个参与者（Participants），第一阶段，协调者向所有参与者发送事务执行请求，参与者执行事务操作并将执行结果（成功或失败）反馈给协调者，如果所有参与者都反馈成功，协调者在第二阶段发送提交请求，参与者正式提交事务；如果有任何一个参与者反馈失败，协调者在第二阶段发送回滚请求，所有参与者回滚事务。
优点
- 原理简单，实现相对容易，它能够在一定程度上保证事务的原子性，适用于对一致性要求较高的场景。
缺点
- 存在同步阻塞问题，在第一阶段，参与者等待协调者的决策，在第二阶段，参与者等待协调者的提交或回滚指令，这期间会阻塞资源，而且协调者存在单点故障风险，如果协调者崩溃，可能导致整个分布式事务处于不确定状态。
2、三阶段提交（3PC）
原理
- 3PC在2PC的基础上进行了改进，它分为CanCommit、PreCommit和DoCommit三个阶段，在CanCommit阶段，协调者询问参与者是否可以执行事务；在PreCommit阶段，如果参与者反馈可以执行，协调者发送预提交指令，参与者执行事务操作并将结果反馈给协调者；在DoCommit阶段，协调者根据参与者的反馈决定是提交还是回滚事务。
优点
- 相比2PC，3PC在一定程度上解决了2PC的同步阻塞问题，如果在PreCommit阶段协调者崩溃，参与者可以根据自身情况进行提交或回滚操作，减少了事务的不确定性。
缺点
- 实现复杂，性能开销较大，并且在某些极端情况下仍然可能出现数据不一致的问题。
3、补偿事务（TCC）
原理
- TCC将一个分布式事务拆分为三个操作：Try、Confirm和Cancel，Try阶段主要是对业务资源进行检查和预留，例如在电商系统中，订单服务在Try阶段会检查商品库存是否足够并进行预留；Confirm阶段是真正执行事务提交操作，将预留的资源进行实际的业务操作，如扣减库存、增加销售额等；Cancel阶段则是在事务需要回滚时，释放Try阶段预留的资源，比如归还库存。
优点
图片来源于网络，如有侵权联系删除
- 具有较好的灵活性，对业务的侵入性相对较小，可以根据业务需求自定义Try、Confirm和Cancel操作，并且不依赖于数据库本身的事务机制，适用于微服务架构下不同类型的服务之间的分布式事务处理。
缺点
- 业务逻辑复杂，需要编写大量的补偿逻辑代码，并且在高并发场景下，如何保证Try、Confirm和Cancel操作的幂等性是一个挑战。
4、本地消息表（异步确保型）
原理
- 本地消息表的基本思想是将分布式事务的操作通过消息的形式进行异步处理，在业务操作的同时，将需要执行的其他操作（如调用其他服务或更新其他数据库）以消息的形式记录在本地消息表中，然后通过一个单独的消息处理程序不断扫描本地消息表，将消息发送出去并执行相应的操作，如果操作成功，标记消息为已处理；如果操作失败，可以进行重试。
优点
- 实现简单，适用于对最终一致性要求较高的场景，它将分布式事务的处理异步化，减少了对业务流程的阻塞，提高了系统的整体性能和吞吐量。
缺点
- 存在消息丢失、消息重复消费等问题，需要额外的机制来保证消息的可靠性，如消息的持久化存储、消息的幂等性处理等。
分布式事务中的一致性问题
1、强一致性
概念
- 强一致性要求在分布式事务提交后，所有节点能立即看到相同的数据状态，这意味着无论从哪个节点读取数据，都能得到最新的、一致的结果，在金融交易系统中，转账操作完成后，无论在哪个网点查询账户余额，都应该立即显示更新后的余额。
实现挑战
- 在分布式环境下实现强一致性非常困难，因为要保证所有节点同时更新数据并且数据一致，需要解决网络延迟、节点故障等问题，2PC和3PC等协议在一定程度上是为了实现强一致性，但它们存在性能和可用性方面的问题。
2、弱一致性
概念
- 弱一致性允许在分布式事务提交后，不同节点的数据可能存在一定的延迟和不一致，但最终会达到一致状态，在一些社交网络系统中，用户发布一条动态后，可能不同的好友在不同的时间看到这条动态，存在一定的时间差，但最终所有好友都能看到这条动态。
实现方式
- 本地消息表等异步处理方式往往实现的是弱一致性，通过不断地重试和数据同步机制，最终使系统达到一致状态。
3、最终一致性
概念
图片来源于网络，如有侵权联系删除
- 最终一致性是弱一致性的一种特殊形式，它强调的是在经过一段时间后，所有节点的数据会自动收敛到一致状态，这是一种更宽松的一致性要求，在很多分布式系统中被广泛应用，在分布式缓存系统中，当数据更新时，缓存可能不会立即更新，但经过一段时间（如缓存过期时间到了或者有数据同步机制触发），缓存中的数据会与数据库中的数据一致。
实现策略
- 可以采用基于时间的策略，如设置缓存的过期时间，到期后重新从数据源获取数据；也可以采用基于版本号的策略，当数据源的数据版本更新时，通知相关的缓存或其他节点进行数据更新。
分布式事务在实际场景中的应用
1、电商系统中的订单处理
- 在电商系统中，一个完整的订单处理流程涉及多个子系统的操作，当用户下单时，订单服务需要创建订单记录，库存服务需要扣减库存，支付服务需要处理支付等，这是一个典型的分布式事务场景。
- 如果采用2PC协议，订单服务可以作为协调者，库存服务和支付服务作为参与者，在第一阶段，订单服务向库存服务和支付服务发送事务执行请求，库存服务检查库存是否足够并执行预扣减操作，支付服务进行支付前的验证；如果都成功，在第二阶段，订单服务发送提交请求，库存服务正式扣减库存，支付服务完成支付，订单状态更新为已支付。
- 如果采用TCC模式，在Try阶段，库存服务检查库存并预留，支付服务冻结用户账户相应金额；在Confirm阶段，库存服务扣减库存，支付服务扣除账户金额；在Cancel阶段，如果订单创建失败或者用户取消订单，库存服务释放预留库存，支付服务解冻账户金额。
2、金融系统中的转账操作
- 在金融系统中，转账操作涉及到源账户所在的银行系统和目标账户所在的银行系统，这两个系统可能是独立的，并且数据存储和业务逻辑处理是分开的。
- 采用3PC协议时，在CanCommit阶段，协调者（可以是转账处理中心）询问源账户和目标账户所在系统是否可以进行转账操作；在PreCommit阶段，如果都可以，协调者发送预提交指令，源账户系统冻结转出金额，目标账户系统准备接收金额；在DoCommit阶段，源账户系统扣除金额，目标账户系统增加金额。
- 如果采用本地消息表方式，当源账户系统执行转账操作时，同时将转账信息记录在本地消息表中，然后通过消息处理程序将消息发送到目标账户系统，目标账户系统接收到消息后进行金额增加操作，如果操作失败可以进行重试，直到转账操作成功。
面试中的常见问题及回答思路
1、请简要介绍一下分布式事务的几种实现模式及其优缺点
回答思路
- 首先分别阐述2PC、3PC、TCC和本地消息表的原理，对于2PC，要强调协调者和参与者的角色以及两个阶段的操作流程，指出其优点是原理简单、能保证原子性，缺点是同步阻塞和协调者单点故障，对于3PC，说明它对2PC的改进之处，如解决部分同步阻塞问题，但也存在实现复杂等缺点，对于TCC，详细解释Try、Confirm和Cancel三个操作的含义和作用，提及它的灵活性和对业务的侵入性，以及在高并发下幂等性的挑战，对于本地消息表，描述其异步处理的思想，优点是实现简单、提高性能，缺点是消息可靠性问题。
2、在分布式事务中如何保证数据的一致性？
回答思路
- 先区分强一致性、弱一致性和最终一致性的概念，对于强一致性，说明在分布式环境下实现的困难以及相关协议（如2PC、3PC）的努力和局限性，对于弱一致性和最终一致性，阐述一些常见的实现方式，如本地消息表对于最终一致性的实现，包括消息的处理、重试机制等，还可以提及基于时间和版本号的策略在保证一致性方面的作用。
3、如果让你设计一个分布式事务解决方案，你会考虑哪些因素？
回答思路
- 首先考虑业务需求，如对一致性的要求是强一致性还是最终一致性，如果是金融交易等对一致性要求极高的场景可能倾向于强一致性的解决方案（如2PC或3PC的改进版），如果是社交网络等对实时性要求不高的场景可以选择最终一致性的方案（如本地消息表或TCC），其次考虑系统的性能和可用性，避免采用会造成严重同步阻塞的方案（如2PC的简单形式），还要考虑系统的架构特点，例如在微服务架构下，TCC可能更适合因为它对业务的定制性强，并且不依赖于特定数据库的事务机制，要考虑故障处理能力，如节点故障、网络故障时如何保证事务的正确执行和数据的一致性，是否有相应的恢复机制，要考虑开发和维护成本，一些复杂的协议（如3PC）虽然在理论上有优势，但实现和维护成本高，需要权衡。
评论列表