消息中间件

一、现象与背景 去年我们做消息平台迁移，把一条核心的订单事件链路从 RocketMQ 切到 Kafka 3.5（5 节点，"order-event" topic 48 分区，消费组 16 实例，峰值约 6.2 万 msg/s，单条平均 1.

【背景】 我们的计费服务用 Kafka 3.5（3 节点，topic "billing-usage" 24 分区）做用量采集，消费组 12 实例（K8s Deployment，滚动发布）。消费逻辑：读消息 → 写入本地 Caffeine 缓

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

一、现象：开了幂等，吞吐没涨，顺序却「看起来」更乱了 先给结论："enable.idempotence=true" 不是「加个开关就完事」，它会悄悄把 "max.in.flight.requests.per.connection" 从你写的

背景 做异步事件链路，每个团队迟早要回答同一个问题：事件（event）到底带全量字段（fat event / fat payload），还是只带一个业务 ID，让下游自己去拉详情（thin event / thin payload）？ 我在

【背景】 我们用 Kafka 2.8（3 broker，ISR=3）承载订单状态流转这条关键链路：topic "order-state"，8 个分区，消费组 8 实例（1:1 部署，保证每个分区内严格顺序）。下游是 MySQL 8.0 写订

一、背景：重复消息不可怕，可怕的是「去重表」先把自己撑爆 去年我们重构订单回调链路：Kafka 3.5（3 节点，"order-callback" topic 16 分区）→ 消费组 8 实例 → MySQL 8.0 落库。日均消息量约 3

【背景】 我们有一条对账链路：Kafka 3.6（3 节点，topic 12 分区）→ 消费者组 6 实例 → MySQL 8.0（单主+1 从，半同步）。消费逻辑：读消息 → 写 MySQL 对账表（REQUIRES_NEW）→ 调用 s

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

一、现象与背景 去年 Q4，我们的支付对账系统开始报「重复记账」。对账服务以 Kafka 消费组形式消费 "pay-notify" topic，该 topic 有 32 个分区，消费组 12 个实例，日均消息量约 4200 万条。某天早高峰

背景：我在一个订单履约服务里用 Kafka（3.5，3 节点）做异步落库，消费组 4 个 consumer，topic 6 分区，平时 lag 基本在 0~50 之间。 现象：过去两周出现 4 次间歇性 lag 飙升，单次峰值到 18 万~