京公网安备11010502063487号`cleanup.policy=compact` 的 topic 不按时间或大小删数据，而是保证"每个 Key 至少保留最新的一条"。这次给 10 个 Key 各写 5 轮更新，中途给其中一个 Key 写一条墓碑（value 为 null），跨三个 Segment，然后读出清理前
磁盘写满是运维里最怕的 Kafka 故障之一。这次没有靠推测，而是在一个独立的小容量磁盘镜像上单独起了一个 Kafka 4.3.1 broker（不影响主集群，也不碰系统盘），一路写到磁盘满，记录 broker 的日志、进程状态、客户端看到的现象，以及扩容之后的恢复过程。
Leader 所在的 Broker 崩溃后，剩下的副本会接管，这一点前面的文章已经验证过。这篇关心的是客户端的真实体验：正在持续写入的 Producer 会中断多久、会不会报错、丢不丢消息，以及日志里留下了什么痕迹。这次让 Producer 用 `acks=all` 加幂等（`e
默认情况下，只有 ISR 里的副本才能成为新 Leader。`unclean.leader.election.enable=true` 允许一个不在 ISR 里、数据落后的副本上位。这次在真实集群里把这个场景完整走一遍：先让 Follower 掉出 ISR，Leader 独自写入
Kafka Consumer 的 `poll()` 不只是"拿数据"，它还是消费者向组协调器证明"我还活着并且在处理"的方式：`max.poll.interval.ms` 规定两次 `poll()` 之间最长能隔多久。这次用一个真实的 Java Consumer，在 poll 之
同一个 `group.id` 下的多个消费者会瓜分一个 topic 的 Partition，成员一变，分配就重新洗牌（rebalance）。这次给一个 6 分区的 topic 依次加入 3 个消费者、再依次让其中两个离开，用真实的 `ConsumerRebalanceListen
可以，而且这是分区数多于消费者数时的常态：一个消费者会同时持有多个分区。真正的问题是它读到的顺序是什么样的。这次往一个 6 分区的 topic 里按序号 0 到 599 依次发送 600 条消息（37 个不同的 key），再用同一个消费组里的单个 Java Consumer 读回
同一个消费组里，一个分区同一时刻只会分给一个消费者，所以消费者数量超过分区数没有意义，分区数不能被整除时会有人多干活。这次用真实数据量化这两点：一个 6 分区的 topic，每个分区 1000 条、共 6000 条消息，每条消息处理时模拟 `Thread.sleep(1)`，分别
常见说法是"消费组里加一个实例会触发 rebalance，所有人暂停消费"。这次用真实数据检验这句话：一个 6 分区的 topic，Producer 以约每 5 毫秒一条的速度持续写入；消费者 A 先独占全部分区，9 秒后再启动消费者 B；对每个分区统计"消息从产生到被消费"的最
`partition.assignment.strategy` 决定分区怎么分给消费组成员。这次用同一个场景把四种内置策略各跑一遍：三个 topic（分别有 3、2、4 个分区，共 9 个分区）被同一个消费组订阅，消费者按 C1、C2、C3 的顺序依次加入，然后 C2 离开。每个
每个消费组都由集群里的某一个 Broker 担任 Group Coordinator，负责成员管理、rebalance 和 offset 存储。这个"某一个"是怎么选出来的、offset 到底存在哪、这个 Broker 挂了会怎样，都能用真实数据回答。这次做了三件事：把 6 个组
Offset 提交决定了消费者重启后从哪里继续读。自动提交、`commitSync()`、`commitAsync()` 三种方式的区别不只是"写起来方不方便"。这次量了它们的开销，验证了 `commitSync()` 不带参数时提交的到底是哪个位置，并看了异步提交失败时代码是怎