数据概览
0
粉丝
1
关注
1
获赞
0
被收藏
0
被评论
378
浏览
0
回答
0
被采纳
0.0%
采纳率
4
信誉
110
积分
0
任务收益
首次发声
已解锁
发布第一篇内容
高山仰止
已解锁
内容被他人引用 1 次
背景 我们有一个 Kafka 消费者组，消费的是 "order-event" topic，该 topic 有 24 个分区，消费组 8 个实例。最近在流量高峰期间，出现了多次 Rebalance 风暴，导致消息处理延迟甚至丢失。 具体环境：
背景 社区对 outbox 表 + CDC 的选型已经讨论得比较透了（见下方引用），我这边已经落地了 outbox + Debezium + Kafka Connect 方案，但踩了一个隐蔽的坑：outbox 表本身的生命周期操作（状态流转
背景 Kafka 3.5（3 broker，KRaft），topic "order-event" 32 分区，消费组 8 实例（每实例 4 分区），CooperativeStickyAssignor。 关键配置："max.poll.reco
«结论先行：线上事故要补消息，绝不要直接在生产消费组上 seek。正确姿势是拉一个全新的独立 replay 消费组，把它的位点 seek 到目标时间戳，限速重放，靠业务层幂等兜底。这套东西我们跑了三年，下面把每个坑都讲透。» 一、现象与背景