消费组

«结论先行：线上事故要补消息，绝不要直接在生产消费组上 seek。正确姿势是拉一个全新的独立 replay 消费组，把它的位点 seek 到目标时间戳，限速重放，靠业务层幂等兜底。这套东西我们跑了三年，下面把每个坑都讲透。» 一、现象与背景

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

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

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

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