消费组重平衡，队列堆积了 30 万条 我们一个交易通知服务用 RocketMQ 4.9 做消费，某天上午扩容，新增 2 个消费者实例。按理说扩容应该更快，结果监控上"消费积压"从 0 飙到 30 万条，持续了 20 多分钟才消化完。组员在群里贴了张图："加机器反而更慢了？" 根因在老架构上：Rock
起因：财务对账时发现的几十笔差异 8 月初，财务同事甩过来一张表：7 月份有 63 笔订单，用户积分扣了但优惠券没发。我们日均 12 万单，63 笔占比万分之五，但财务按笔核对，一笔都不能有。 查下来问题出在下单流程。下单成功后要发一条消息给营销服务，让它发优惠券： @Transactional p
需求：30 分钟未支付自动关单 产品提了个很常见的需求：用户下单后 30 分钟没支付，自动关闭订单并释放库存。我们日均订单 12 万，粗略统计落在 30 分钟窗口内未支付的约 3.4 万单。 这个需求本质是"延迟任务"，实现方式有好几种，我基本都试过，把各自的坑记一下。 方案一：定时扫表 最朴素的写
同事问：订单状态怎么倒着走了 做微服务改造时，订单状态变更要通过 MQ 广播给下游（积分、优惠券、物流、通知）。上线一周后，物流组的同事找过来："你们发的消息顺序不对，我这边先收到'已发货'，后收到'已付款'，状态机直接报错。" 我看了一眼他的日志，确实是反的： 14:03:21.114 收到订单消
运营找上门：同一笔积分被发了两次 七月的一个下午，运营拿着工单来找我："用户 88372 投诉，说下单后积分到账两次，多领了 300 积分。" 我第一反应是代码里有循环或者被调用了两次。翻了消费日志，同一个 msgId 确实处理了两遍： 2020-07-05 14:22:31.117 [Consum
财务对账少了 38 笔，消息不知道去哪了 1 月 10 号早上，财务那边甩过来一张表：12 月的积分发放记录比订单表少了 38 笔。我们发积分是下单成功后发一条 ORDER_PAID_TOPIC，积分服务消费它加积分。订单在，积分没加，说明消息在中途没了。 38 笔，占当月 47 万订单的万分之零点
