京公网安备11010502063487号`partition.assignment.strategy` 决定分区怎么分给消费组成员。这次用同一个场景把四种内置策略各跑一遍：三个 topic（分别有 3、2、4 个分区，共 9 个分区）被同一个消费组订阅，消费者按 C1、C2、C3 的顺序依次加入，然后 C2 离开。每个
每个消费组都由集群里的某一个 Broker 担任 Group Coordinator，负责成员管理、rebalance 和 offset 存储。这个"某一个"是怎么选出来的、offset 到底存在哪、这个 Broker 挂了会怎样，都能用真实数据回答。这次做了三件事：把 6 个组
Offset 提交决定了消费者重启后从哪里继续读。自动提交、`commitSync()`、`commitAsync()` 三种方式的区别不只是"写起来方不方便"。这次量了它们的开销，验证了 `commitSync()` 不带参数时提交的到底是哪个位置，并看了异步提交失败时代码是怎
`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 宕机场景
给定一个整数数组 `nums` 和一个目标值 `target`，找出数组中和为 `target` 的两个元素，返回它们的下标。题目保证恰好有一个答案，同一个位置的元素不能用两次。这道题的核心是把"找另一半"从逐个比较换成哈希表查找。本文用真实测量对比两种写法在不同规模下的耗时，验
给定一个 32 位有符号整数 `x`，返回把它的数字部分反转后的结果；如果反转后超出 32 位有符号整数的范围 `[-2^31, 2^31 - 1]`，返回 0。题目还规定环境不允许存储 64 位整数，所以不能先用更宽的类型算出结果再比较。这道题没有值得做成动画的动态过程，难点全