Kafka

【背景】 我们用 Kafka 3.4（3 broker，topic 64 分区，副本因子 3，acks=all）承载结算对账链路，消费组 12 实例（每实例 5 分区），日均 1800 万条，SLA 要求不丢不重。下游是 MySQL 8.0

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

背景 热榜上连接池 P99、超时重试、Kafka 事务、mTLS、K8s 探针都被聊透了，站内也已经有几篇关于「重试退避 + 死信」「幂等分层」「异步化 + 幂等」的讨论。但我发现一个更前置的架构分叉没人正面聊过——内部任务到底该走 Kaf

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

背景 我负责一条埋点事件流管道：Kafka 16 分区（单 broker 3C 部署），消费组 8 实例，每实例起 4 个 worker 线程，按 partition 分片（即每个 partition 固定绑 1 个 worker，分区内严

【背景】 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

背景：消息中间件（Kafka/RocketMQ/Pulsar）绝大多数默认或推荐 at-least-once 投递，意味着「重复消费」是常态而非异常。我在这行做了 15 年，见过太多团队把幂等当成「加一个唯一索引就完事」的事，结果线上要么吞

【背景】 最近复盘了几次线上 P99 抖动，根因高度雷同：某个原本"同步直调下游"的接口，在下游一次 GC 或慢查询时，把上游线程池拖满，最终雪崩。事后大家都说"这里早该上 Kafka 异步化了"，但当时为什么没上？我把它拆开看，其实不是"

背景 上周我们一条退款链路出了一次典型的「幂等设计翻车」：退款服务对同一笔订单 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

【背景】 我用 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 天历史，

«先抛一个我想听大家拍砖的问题：你把 producer 设成 "acks=all"，是不是就真觉得"我这一条消息绝不会丢"了？ 我去年在压测环境里被它打了一次脸，今天把账算清楚。» 一、现象与背景：一次"看起来万无一失"的丢消息 去年 10

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

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

【背景】 Kafka 3.5（3 broker，rack 分布，ISR=2），topic "order-flow" 32 分区，producer 8 实例（Spring Kafka 3.1，每实例一个 producer 对象），日均约 18

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