面试题：Ruby微服务架构下的分布式事务处理

Question

在基于Ruby的微服务架构中，当涉及多个微服务协同完成一个业务操作，需要保证数据一致性时，分布式事务处理是一个关键问题。请阐述你对分布式事务的理解，以及在Ruby微服务架构中，你会采用哪些方案来处理分布式事务，每种方案的适用场景和可能面临的挑战是什么？

Answer 1

对分布式事务的理解

分布式事务是指在分布式系统中，涉及多个不同的服务或数据源，需要保证这些操作要么全部成功提交，要么全部回滚，以维持数据的一致性。与传统的单机事务不同，分布式事务面临网络延迟、节点故障、数据一致性等更多复杂问题。

在Ruby微服务架构中处理分布式事务的方案

1. 两阶段提交（2PC）
   • 适用场景：适用于对数据一致性要求极高，且各个微服务之间的交互较为紧密，性能要求相对不是极端高的场景。例如银行转账场景，涉及到转出账户和转入账户两个微服务，要求资金的增减必须准确一致。
   • 面临挑战：
     • 单点故障：协调者节点一旦出现故障，整个分布式事务可能会陷入阻塞状态。
     • 性能瓶颈：两阶段的提交过程涉及多次网络交互，在高并发场景下性能较差。
     • 数据不一致风险：在第二阶段，如果部分参与者出现网络故障，可能导致部分提交成功，部分失败，产生数据不一致。
2. 补偿事务（TCC - Try - Confirm - Cancel）
   • 适用场景：适用于业务逻辑相对复杂，对性能有较高要求，且允许一定程度最终一致性的场景。比如电商订单系统，在下单、扣库存、支付等一系列操作中，若某个环节失败，可以通过补偿操作恢复到事务开始前的状态。
   • 面临挑战：
     • 业务侵入性：需要在业务代码中实现Try、Confirm、Cancel三个操作，对业务代码侵入性较大。
     • 补偿逻辑复杂性：编写合适的补偿逻辑较为复杂，需要考虑各种异常情况，确保数据最终一致性。
3. 本地消息表
   • 适用场景：适用于业务场景中可以接受一定延迟来保证数据一致性的场景。例如异步的订单处理，订单创建后异步处理库存、物流等后续操作。
   • 面临挑战：
     • 消息可靠性：需要确保消息的可靠传递，防止消息丢失或重复消费，这需要额外的机制来保证，如消息确认和幂等性处理。
     • 数据一致性延迟：由于是异步处理，数据一致性存在一定延迟，不适用于对一致性要求极高的场景。
4. 可靠事件发布/订阅
   • 适用场景：适用于微服务之间解耦性要求较高，允许一定程度的最终一致性的场景。例如电商系统中，订单状态变更后，通知库存、物流、营销等多个微服务执行相应操作。
   • 面临挑战：
     • 事件一致性：需要保证事件的可靠发布和订阅，防止事件丢失或重复，确保各个微服务基于相同的事件状态进行处理。
     • 系统复杂度：引入事件总线等组件增加了系统的复杂性，需要管理事件的版本、路由等。