订单与库存互调为何会卡死：用 Trace 找循环依赖并改成事件驱动

订单与库存互调为何会卡死用 Trace 找循环依赖并改成事件驱动先确认订单与库存是否形成循环等待如果 Order Service 同步等待 Inventory Service而库存处理又回调订单查询两个线程池可能在流量上升时互相占住。504、低 CPU 和线程池满只能提示等待不能直接写成线上结论。在测试环境构造一条循环调用用jstack和 SkyWalking 对齐调用方向、超时与线程状态。并发、响应时间和错误率都从演练采集# 提取 Order Service 节点的线程转储快照 jstack pid /tmp/order_thread_dump.txt # 分析 Order Service 中处于 WAITING/BLOCKED 状态的 Dubbo 线程 cat /tmp/order_thread_dump.txt | grep DubboServerHandler -A 10 | grep java.lang.Thread.State | sort | uniq -c # 检索 SkyWalking 慢追踪链条上的调用环路 curl -s http://skywalking.internal/api/trace/search \ -d {serviceId:order-service,status:ERROR} | jq .下面是构造循环调用时可能出现的等待栈。它只能说明线程正在等待 RPC必须再与另一侧线程栈和 Trace 对齐DubboServerHandler-sample-endpoint-thread daemon TIMED_WAITING java.lang.Thread.State: TIMED_WAITING (parking) at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.parkNanos.java:215) at com.alibaba.dubbo.rpc.protocol.dubbo.DubboInvoker.doInvoke(DubboInvoker.java:108) at com.architecture.inventory.api.InventoryService.deductStock(Native Method) at com.architecture.order.service.OrderServiceImpl.createOrder(OrderServiceImpl.java:88)统计两个服务中等待相关 RPC 的线程数并记录线程池上限。若订单侧等待InventoryService.deductStock()同时库存侧等待OrderService.validateOrderDiscount()且可用线程持续降到无法处理回调才形成循环等待证据。循环依赖为何会耗尽两侧线程池在单体架构时代两个 Service 之间互相Autowired循环调用Spring 尚能通过三级缓存进行 Bean 循环依赖解耦或在运行时同线程直接调用。然而一旦将单体拆分为分布式微服务循环调用就会演变为分布式资源死锁Distributed Thread Deadlock。当并发流量陡增时订单服务的线程池被 200 个请求占据并向库存服务发起deductStock()RPC库存服务处理时又反向调用订单服务的validateOrderDiscount()。当正向请求占住订单线程而库存又同步回调订单两个池都可能等待对方释放资源。线程数量与超时从演练配置读取是否形成循环要用 Trace 和线程栈确认。候选重构事件驱动与显式状态机降低循环等待风险的直接做法是保持同步依赖单向反向通知可评估事件或查询副本。引入消息后还要处理重复、乱序、积压和补偿不能只看线程池变化。一种候选方案是事务消息配合本地消息表把反向同步调用改为异步事件。它提供的是可恢复的最终一致流程仍需验证重复、乱序、积压与对账。核心重构代码实现package com.architecture.order.event; import org.apache.rocketmq.client.producer.LocalTransactionState; import org.apache.rocketmq.client.producer.TransactionListener; import org.apache.rocketmq.common.message.Message; import org.apache.rocketmq.common.message.MessageExt; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.stereotype.Service; import org.springframework.transaction.annotation.Transactional; Service public class OrderEventDrivenService implements TransactionListener { private static final Logger log LoggerFactory.getLogger(OrderEventDrivenService.class); private final LocalOrderRepository orderRepository; public OrderEventDrivenService(LocalOrderRepository orderRepository) { this.orderRepository orderRepository; } /** * 1. 执行本地订单创建事务反向通知由事件链路处理 */ Override Transactional public LocalTransactionState executeLocalTransaction(Message msg, Object arg) { try { String orderPayload new String(msg.getBody()); log.info(开始执行本地订单落库事务, Payload: {}, orderPayload); // 本地落库初始状态设置为 PRE_CREATED orderRepository.savePendingOrder(orderPayload); // 本地事务成功提交 RocketMQ 半消息 return LocalTransactionState.COMMIT_MESSAGE; } catch (Exception e) { log.error(本地订单创建失败, 回滚 MQ 半消息, e); return LocalTransactionState.ROLLBACK_MESSAGE; } } /** * 2. MQ 事务状态回查逻辑 */ Override public LocalTransactionState checkLocalTransaction(MessageExt msg) { String orderId msg.getKeys(); boolean exists orderRepository.checkOrderExists(orderId); return exists ? LocalTransactionState.COMMIT_MESSAGE : LocalTransactionState.ROLLBACK_MESSAGE; } }在库存服务端可以消费OrderCreatedEvent异步扣减并让该处理函数不再回调订单服务。系统中的其他调用仍需通过 Trace 扫描package com.architecture.inventory.event; import org.apache.rocketmq.spring.annotation.RocketMQMessageListener; import org.apache.rocketmq.spring.core.RocketMQListener; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.stereotype.Service; Service RocketMQMessageListener( topic ORDER_CREATED_TOPIC, consumerGroup inventory_deduct_group ) public class AsyncInventoryDeductConsumer implements RocketMQListenerString { private static final Logger log LoggerFactory.getLogger(AsyncInventoryDeductConsumer.class); Override public void onMessage(String orderCreatedEventJson) { log.info(异步接收到订单创建事件, 开始无锁化扣减库存: {}, orderCreatedEventJson); // 执行本地库存扣减逻辑如果失败发布 INVENTORY_DEDUCT_FAILED 事件供订单服务兜底退款 // 此处理路径不发起反向同步 RPC失败进入明确的补偿与对账流程 } }用同一演练验证解耦结果在 Staging 使用固定请求集比较循环 RPC 与事件驱动方案。负载大小按环境容量设置还要验证消息重复、乱序和消费失败指标采集来源要回答的问题请求响应时间与超时数负载工具、入口 Trace事件链路是否改善入口等待同时引入新的排队延迟两侧 RPC 活跃与等待线程线程池指标、线程转储反向同步等待是否仍会耗尽可用线程订单、库存最终状态业务库、消息消费和对账记录重复、乱序或消费失败后能否收敛到合法状态循环调用与消息积压Trace 拓扑、Broker 指标循环是否消失压力是否只是转移到消息队列分布式服务拆分的三项检查避免双向同步 RPC发现A - B且B - A时先确认能否调整领域边界或把反向依赖改为事件、查询副本等单向接口。读写分离与数据冗余如果库存服务需要验证订单的折扣应该在库存服务本地的缓存/数据库中冗余必需的折扣快照字段而不是在运行时跨网络去 RPC 查订单服务。评估异步最终一致性跨服务变更可考虑事务消息或 TCC但要先定义幂等、补偿和对账方式。异步不能消除问题只是把一致性处理移到可管理的位置。