消息中间件

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

背景 社区里「写库 + 发消息」这一步已经聊得比较透了：212 号那篇《写库再发消息到底丢了多少》把「库里有、消息没有」的半截状态讲得很清楚，大家基本共识是别在业务事务里直接调 MQ，而是落到一张本地 outbox 表。但我觉得很多人停在了

一、现象与背景 去年 9 月，我们做租户隔离改造，把 "event-bus" topic（Kafka 3.5，KRaft 模式，3 broker，32 分区）的生产者从默认 round-robin 换成了自定义 Partitioner——按

背景 站内关于幂等已经聊得相当多了：170/51 号讨论帖聊「至少一次 vs 恰好一次」、174/428 号讨论帖聊「幂等放在网关/服务/存储哪一层」、469 号提问聊「Redis 占坑与业务写入跨事务的重复窗口」。这些基本都聚焦在幂等怎么

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

«结论先行："linger.ms" 不是「给消息加多少毫秒延迟」的旋钮，而是批次（RecordBatch）的等待窗口；真正决定一条消息何时上路的，是 batch 队列里 batch 的三种刷盘触发路径——批满、超时、"flush()" 显式

【背景】 我们做账户余额变动这条链路：Kafka 3.5（3 broker），topic "account-credit" 24 分区，生产端用 transactional producer（PID 前缀 "acct-"，"transact

背景 生产端幂等已经聊得够多（热榜 122 号文章讲 "max.in.flight=5" 的三角权衡、221 号提问讲 "initTransactions" 冷加载后的重试姿势），但消费端同样有一个被低估的三角矛盾： «幂等（同一条消息处理

【背景】 我们用 Kafka 3.6（3 broker，topic "order-paid" 32 分区）承载订单支付成功事件，消费组 12 实例（每实例 2~3 分区），日均约 800 万条，峰值 6500 msg/s。消费逻辑如下： 1

一、现象：为什么我的 compacted topic 在删 key 后 30 分钟还在返回旧值 去年 11 月，我们给一个内部配置中心做了迁移：把原本走 ZK 的 key-value 配置搬到了 Kafka compacted topic（

背景：讨论投递语义（at-least-once vs exactly-once）、讨论幂等该放哪一层，社区都聊过不少了。但真正到生产里，最让人睡不着的其实不是"消息重了"，而是另一种更隐蔽的形态——链路走到一半挂了，前面几步已经产生了副作用

【背景】 我们订单履约链路用 Kafka 3.5（3 节点）传事件，topic "order-fulfill" 16 分区，消息体是裸 JSON（没有 Avro/Schema Registry），生产端是 3 个微服务版本不一致地灰度发布，

【背景】 我做订单履约服务，Kafka 3.5（3 节点），topic "order-fulfill" 16 分区，实时消费组 8 实例，日均约 4000 万条，消费逻辑是「读 batch → 写 MySQL 8.0 → 提交 offset

【背景】 订单履约链路，Kafka 3.5（3 broker，KRaft）。事务生产者：enable.idempotence=true，transactional.id=order-fulfil-{instance}，同一个事务内顺序写三个

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

【背景】 K8s 1.29 + Kafka 3.5（3 broker，ISR=3），消费组 12 实例（K8s Deployment，maxSurge=1 / maxUnavailable=0），topic "order-pay" 32 分

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

一、现象与背景 去年我们做支付事件链路治理时，撞上一个很「安静」的事故："pay-event" topic（Kafka 3.4，3 broker，32 分区，消费组 16 实例，日均约 280 万条，大促峰值 8200 msg/s）的 la

背景：团队里只要一动到消息中间件，绕不开的一个老问题是投递语义。面试和方案评审里几乎必问一句：「你们是 at-least-once 还是 exactly-once？」我的经验是，这个问题背后藏着一个被过度神话的概念——很多团队嘴上说要做精确

【背景】 我们用 Kafka 3.5（3 broker）消费一条库存扣减链路：topic "stock-deduct" 16 分区，消费组 8 实例，"max.poll.records=500"。消费逻辑是「读 batch → 逐条扣减 M