RocketMQ

一、现象：一条毒消息，30 秒内把 4 个队列打到 0 QPS 去年大促前压测，我们的订单事件流（RocketMQ 5.1.4，4 个 Queue，消费端 8 线程）在 QPS 5200 时突然出现「消费延迟从 200ms 飙到 47s」，

背景：消息中间件（Kafka/RocketMQ/Pulsar）绝大多数默认或推荐 at-least-once 投递，意味着「重复消费」是常态而非异常。我在这行做了 15 年，见过太多团队把幂等当成「加一个唯一索引就完事」的事，结果线上要么吞

【背景】 我们用 RocketMQ 4.9.7（3 broker 集群）承载「订单状态变更 → 推送下游营销/风控」链路：topic "order-status" 32 个 queue，消费组 6 实例（K8s Deployment，1 副

背景 社区里 K8s 版本升级的姿势已经聊过一轮（滚动 / 蓝绿 / 双集群并存），但消息队列这类有状态中间件的大版本升级，我观察到的分歧远比 K8s 大，而且很少有人正面摊开讲。 我 5 年中间件研发，经历过三次 MQ 大版本切换：一次

【背景】 我们用 RocketMQ 4.9.7（3 broker 集群）承载「订单创建 → 扣库存 + 发通知」的异步链路，topic "order-created" 共 32 queue，消费组 8 实例（1:4 部署），日均约 2000

一、现象与背景：不是丢消息，是「丢了一半」 先讲结论：「先写本地库、再发 MQ」这个看起来最朴素的写法，在高并发下丢的不是消息，而是「库里有、消息没有」的半截状态。这类问题比纯丢消息更隐蔽，因为它能通过所有常规监控——库表数据完整、MQ 消

【背景】 RocketMQ 4.9.7（3 broker 集群），topic "order-event" 共 256 个 queue，消费组 8 实例、consumeThreadMin=20 / Max=64，日均 6000 万条，走 at

【背景】 我们用 RocketMQ 4.9.7（3 broker 集群）承载支付清结算的状态机流转：topic "settle-state"，16 个 queue，消费组 4 实例，使用 "MessageListenerOrderly" 保

【背景】 我们用 RocketMQ 4.9（3 节点集群）承载订单扣减库存这条关键链路，采用事务消息保证「扣库存」与「发通知」的最终一致。本地事务执行成功后会 commit，失败/超时则回滚；Broker 侧配置了 transactionC