京公网安备11010502063487号`enable.auto.commit=true` 是默认值，`auto.commit.interval.ms` 默认 5000。大家通常的印象是"自动提交可能重复消费"。这次用真实的崩溃模拟验证：消费者拿到数据后，用 `Runtime.halt()`（等同 `kill -9`，
"先提交还是先处理"决定了崩溃后是重复还是丢失。这次做了一个可以精确审计的实验：3000 条消息、每批 10 条，消费者把处理结果（这里就是把 offset 写进一个 sink 文件）落盘。分别用"先处理再提交"和"先提交再处理"两种顺序，在第 5 批的同一个位置用 `Runti
前面《Consumer 为什么必须调用 poll()》已经看到，处理太慢会让提交失败。这篇换一个视角，看"被踢出"这件事发生的时间线：一个消费者拿到数据后处理 15 秒，另一个同组的备用消费者在旁边等着。记录备用消费者是在什么时刻拿到分区的、拿到的数据和原来那个消费者手里的是不是
这两个参数经常被一起提，但它们管的是两件不同的事：`heartbeat.interval.ms` 是消费者多久向协调者报一次"我还在"，`session.timeout.ms` 是协调者多久没收到心跳就认定这个消费者已经不在了。这次用真实的进程冻结（`kill -STOP`，进程
Kafka 的一个分区是严格按 offset 顺序消费的，消费者没有"先跳过这条"的默认行为。一条无法被反序列化或无法被处理的消息，会让排在它后面的所有消息都拿不到。这次分别验证两种"毒药"：反序列化失败（发生在 `poll()` 内部）和处理逻辑失败（发生在业务代码里），并对比
答案是"在 Kafka 内部的读—处理—写循环里可以，出了 Kafka 就不行"。这次用一个真实的消费—转换—生产程序验证前半句：从 `eos-in` 读 100 条，每条乘 2 后写入输出 topic，处理到第 5 批（offset 40 到 49）时在输出已经发送、但提交尚未
开启幂等后，Broker 靠两样东西识别重复：Producer ID（PID，每个 Producer 实例一个）和每个分区上单调递增的序列号（Sequence Number）。这次先直接看日志文件里这两个字段长什么样，再看幂等对配置的强制要求，最后在真实的 Leader 宕机场景
Kafka 不会把一个 Topic 存成一个不断增长的文件，而是拆成多个 Partition：真实测出 key 决定目标分区、同一个 key 永远落到同一分区、消费者组并行度被分区数卡死。