面试题：分布式系统中分布式事务原子性在实际场景中的体现

Question

请举例说明在分布式系统后端开发中，分布式事务原子性是如何在实际业务场景（如电商的订单创建与库存扣减）中体现的，并阐述保证原子性可能会面临的挑战。

Answer 1

分布式事务原子性在电商订单创建与库存扣减中的体现

1. 订单创建成功，库存扣减成功：假设用户在电商平台下单购买商品，系统先创建订单记录，成功后调用库存系统扣减相应商品库存。若两个操作都顺利完成，整个业务流程符合原子性，即要么都成功，对业务产生预期的完整影响（产生订单且库存减少），要么都不发生。例如，用户购买一部手机，订单系统创建该手机购买订单记录，库存系统成功扣减一部该手机库存，交易正常完成。
2. 订单创建失败，库存不扣减：若订单创建过程中出现问题，如用户信息校验不通过、支付接口异常等导致订单无法创建成功，此时库存系统不应扣减库存。比如用户提交订单时，支付信息有误，订单创建失败，库存仍保持原有数量，保证了原子性，避免库存无端减少。
3. 订单创建成功，库存扣减失败回滚订单：若订单创建成功但库存扣减由于网络故障、库存不足等原因失败，为保证原子性，需要回滚已创建的订单。例如，订单创建成功后，库存系统因网络问题无法扣减库存，此时订单系统需撤销该订单，使业务状态回到初始状态，就好像整个操作从未发生过。

保证原子性面临的挑战

1. 网络问题：分布式系统中各服务间通过网络通信，网络故障（如网络延迟、丢包、中断等）很常见。在订单创建与库存扣减场景中，若订单创建成功后，库存扣减请求因网络延迟未及时到达库存系统，或库存扣减结果因网络中断无法返回给订单系统，会导致订单系统无法确认库存是否成功扣减，难以决定后续操作（是等待、重试还是回滚订单）。
2. 服务可用性：任何一个参与分布式事务的服务都可能出现故障，如库存服务因服务器故障、资源耗尽等原因不可用。当订单创建成功后调用库存服务扣减库存时，若库存服务不可用，就无法完成库存扣减操作，同时订单系统也无法得知何时库存服务恢复可用，以及是否需要在服务恢复后重新发起扣减请求，这对保证原子性带来困难。
3. 数据一致性：不同服务可能使用不同的数据存储方式和机制，数据同步存在延迟。例如订单系统和库存系统分别有自己的数据库，当订单创建成功后，库存系统扣减库存时，若库存数据库的更新操作与订单数据库的操作无法实时同步，可能会出现短暂的数据不一致。在高并发场景下，这种不一致可能导致数据混乱，影响原子性的实现。
4. 事务协调与管理：分布式事务涉及多个服务，需要一个有效的事务协调机制来保证原子性。例如使用两阶段提交（2PC）协议时，协调者需要与所有参与者（订单服务、库存服务等）进行通信，在准备阶段和提交阶段都可能出现协调者故障、参与者响应超时等问题。而且2PC存在单点故障（协调者故障影响全局）、性能瓶颈（所有参与者等待协调者指令，阻塞时间长）等缺点，对于大规模分布式系统，实现高效可靠的事务协调与管理难度较大。