消息中间件

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

背景 社区已经聊了很多"幂等"的上下游：投递语义（at-least-once vs exactly-once）、消费端幂等/顺序/重试三角、Outbox 与本地消息表、重试退避与死信……但有一个最朴素、也最容易在凌晨把人叫醒的问题，似乎还没

«先抛一个我想听大家拍砖的问题：你们线上有没有过这种诡异现象——整机 16 核，CPU 只用了 6%，Kafka lag 却在稳定上涨，加机器也救不回来？ 如果是，八成不是 broker 的锅，也不是 rebalance 的锅，而是「有序性

背景：at-least-once + 消费端幂等已经是社区共识，前面 170 / 51 / 710 / 681 那几篇把幂等表、业务状态机聊得够透。但还有一个更底层、更少被认真掰扯的分歧：offset 提交这个动作，到底代表什么？ 我的理解

【背景】 Kafka 2.8（3 broker，min.insync=2）承载订单事件 topic "order-events"，6 分区，消费组 3 实例（每实例 2 分区）。下游是 MySQL 8.0 写订单表 + Redis 6.2

先抛一个我想听大家拍砖的问题：你们线上消费组的实例数，是不是从来没和 topic 的分区数对齐过？ 我们去年就栽在这儿——扩容只是「多起两个 Pod」，分区数一个没动，结果整组从「几乎不 rebalance」变成「每天平均 47 次 reb

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

背景 上周我们一条退款链路出了一次典型的「幂等设计翻车」：退款服务对同一笔订单 R-20240618-000713 做了三步副作用——① 调支付渠道冲正（外部 API）、② 写账务流水（MySQL 唯一键 order_no + biz_ty

【背景】 生产环境 Kafka 3.4（3 broker，KRaft），topic "user-event"，24 分区，消费组 8 实例（1:3 分区/实例），峰值 1.8 万 msg/s。消费者内部要做一次下游 RPC 落库（P99 约

一、现象与背景：消费端没报错，但下游对不上账 先给结论：在同一个 topic 上，read_uncommitted 和 read_committed 两个消费组"看到的 offset 根本不是同一把尺子"，一旦你在两者之间做迁移、重放或 o

背景：聊「至少一次 + 幂等」的帖子社区里已经不少了（51、170、474、620 号讨论帖都在这条线上），但我带团队落地时反复卡住、也最容易在联调时才爆雷的，是另一个更前置的问题——幂等键（idempotency key / dedup

【背景】 我用 Kafka 2.8（3 broker）承接订单履约事件流，topic 64 分区，消费组 12 实例，consumer 配置：session.timeout.ms=10s、heartbeat.interval.ms=3s、m

【背景】 我们的对账服务用 Kafka 3.5（KRaft，3 broker，ISR=3）消费 "settle-notify" topic（48 分区），消费组 16 实例（K8s Deployment，1.29，maxUnavailabl

«先抛个我想听大家拍砖的问题：你们线上 "auto.offset.reset" 到底设的什么值？设了 "earliest" 就敢拍胸脯说"新消费组一定全量重放"吗？ 我们去年就栽在这儿——设了 "earliest" 依然跳过了 6 天历史，

背景：聊"至少一次 + 幂等"、聊消费端幂等/顺序/重试三角的帖子不少了，但真正落地时最容易被糊弄过去、也最容易在凌晨把人叫醒的，其实是重试本身——重试几次、每次退多久、退避用固定还是指数、要不要加抖动、超过上限之后消息落到哪儿、谁来负责把

【背景】 我们用 Kafka 3.6（3 broker，KRaft）承载支付事件链路。生产者侧 enable.idempotence=true + 事务，transactional.id 固定为 pay-evt-{shard}（按订单分片，

一、现象与背景：重启后不是丢一条，是丢「一批」，而且对账还是平的 先给结论：消费端「攒批落库」时，"offset 提交" 和 "批量 flush 到 MySQL" 这两步谁先谁后，直接决定了故障时你是「静默丢数据」还是「可幂等吸收的重复」。

背景：只要系统里同时存在"写业务库"和"发消息"两件事，就绕不开一个经典问题——怎么保证这两步的原子性。我见过三种主流做法在同一家公司里共存：本地消息表（业务表 + 消息表同库同事务，后台扫表投递）、Outbox 模式（同上但配合 CDC

一、现象与背景：消费端不是慢，是「停摆」 去年我们做支付对账链路，Kafka 3.5（3 节点 KRaft），"pay-settle" topic 16 分区、峰值约 6.2 万 msg/s，消费组 4 实例，"isolation.leve

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