消费组重平衡，队列堆积了 30 万条 我们一个交易通知服务用 RocketMQ 4.9 做消费，某天上午扩容，新增 2 个消费者实例。按理说扩容应该更快，结果监控上"消费积压"从 0 飙到 30 万条，持续了 20 多分钟才消化完。组员在群里贴了张图："加机器反而更慢了？" 根因在老架构上：Rock
对账群里跳出一条消息：同一笔订单扣了两次款 2 月 19 号下午，财务在对账时发现一笔订单出现了两次支付成功记录，金额都是 199 元。看起来是消费者把消息重复处理了。 我们用的 Kafka 是 3.1.0，消费者是 enable.auto.commit=true 默认配置。同事问我：不是说 Kaf
架构评审会上，两个人对着吵了四十分钟 2 月中旬的一次架构评审，议题是"下单链路要不要上 Seata"。后端 A 主张用 AT 模式，理由是几乎不用改业务代码；后端 B 坚持用消息队列做最终一致，理由是"我们承受不了 Seata 挂掉导致下单全挂"。 我最后拍板：全都不用，主链路走本地消息表，退款单
现象：每次发版，消费停 47 秒 9 月底做容量复盘时，我发现一个奇怪的规律：每次发布，Kafka 消费 lag 都会先涨后落，中间有大约 45 到 60 秒消费完全停住。看消费者日志，那段时间全是这个： 2021-09-28 14:22:31.407 WARN [Consumer client
告警：0 点 15 分，堆积 1200 万 8 月 31 号晚上大促，我们值守到凌晨。0 点 15 分，告警响了： [P1] RocketMQ consumer lag: group=order-sync-consumer, topic=ORDER_SYNC_TOPIC diff=1,20
起因：财务对账时发现的几十笔差异 8 月初，财务同事甩过来一张表：7 月份有 63 笔订单，用户积分扣了但优惠券没发。我们日均 12 万单，63 笔占比万分之五，但财务按笔核对，一笔都不能有。 查下来问题出在下单流程。下单成功后要发一条消息给营销服务，让它发优惠券： @Transactional p
需求：30 分钟未支付自动关单 产品提了个很常见的需求：用户下单后 30 分钟没支付，自动关闭订单并释放库存。我们日均订单 12 万，粗略统计落在 30 分钟窗口内未支付的约 3.4 万单。 这个需求本质是"延迟任务"，实现方式有好几种，我基本都试过，把各自的坑记一下。 方案一：定时扫表 最朴素的写
财务对账少了 3 笔积分 2 月中旬，财务同学找过来：2 月 10 号这天的积分发放和订单数据对不上，少了 3 笔。 我们链路是：订单服务发 ORDER_PAID 事件到 Kafka，积分服务消费后发积分。查了一圈，积分服务没报错，是消息压根没到。 先看生产者的配置： spring: kafka
扩容前的一次基准压测 2020 年 11 月，订单事件 topic 的日均写入量从 3000 万条涨到 1.1 亿条，运维要我给个扩容方案。我没直接拍板加机器，先用 kafka-producer-perf-test.sh 在现有 3 台 broker 上跑了一轮，想摸清单机的真实上限。 机器配置：1
上线第二天：生成了两个一样的订单号 十二月十号，我们把自增主键换成了 Snowflake 生成分布式 ID。上线第二天，测试同学在日志里发现了重复： 2020-12-11 10:22:31.114 WARN IdGenerator - 检测到时钟回拨, workerId=3, lastTimest
