京公网安备11010502063487号默认分区器只认哈希值，不认业务含义——想让特定一类消息独占某个分区（比如给高优先级订单单独留一个分区，方便下游优先处理），光靠 key 哈希做不到，因为哈希结果落在哪个分区是不可控的。这次真实写了一个自定义 `Partitioner`，跟默认分区器的真实行为做对比。
消息调用 `send()` 之后不会立刻上网络，而是先进入客户端本地的一块内存缓冲区（`buffer.memory`），按分区攒成批次，再由专门的 Sender 线程异步发出去。这次真实读取 Producer 的内部 Metrics，把缓冲区占用的真实变化过程看一遍，也真实验证了
`acks` 决定 Producer 在什么条件下认为一条消息"写成功"。这次真实做了一个最直接的实验：用只有 1 个副本的 topic，在真实杀掉那个唯一副本所在 Broker 的同时发送消息，分别看 `acks=0` 和 `acks=all` 的真实反应。
Follower 不是被动等 Leader 推送数据，而是主动向 Leader 发 Fetch 请求拉取。这次真实杀掉一个 Follower 所在的 Broker，在它缺席期间真实写入数据，再重启它，真实计时它追上 Leader、重新进入 ISR 需要多久。
前面几篇杀的都是整个 Broker 进程（`kill -9`），ISR 收缩看起来像是"进程死了才会被踢出去"。这次换一种真实的杀法：用 `kill -STOP` 把 Follower 进程真实暂停（进程还活着，只是不再被调度），看它会不会、什么时候被移出 ISR——用来验证 I
LEO（Log End Offset）是一个副本自己的日志真实写到了哪；HW（High Watermark）是这个分区对外（消费者）承诺"读到这里都是安全的"的位置。这次真实用 `kill -STOP` 暂停一个 Follower（进程活着，只是不干活），观察它暂停期间自己的磁盘
"顺序写磁盘"是解释 Kafka 性能时最常见的说法，但这个说法在现代 SSD 上到底还站不站得住脚？这次在真实的 SSD 上分别测了"顺序写 vs 随机写"和"每次强制 fsync vs 交给 OS 批量刷盘"两组对照，用真实数字看看哪个才是真正的原因。
Kafka 的 Broker 是个 JVM 进程，理论上完全可以在堆内存里自己维护一份"最近消息缓存"。但它没有这么做，而是把这件事完全交给操作系统的 page cache。这次真实做了一件很直接的事：写入一批数据、真实测消费速度，然后真实 `kill -9` 整个 Broker
一个 Partition 在磁盘上不是一个大文件，而是一个目录，里面是按大小切开的多个 Segment。这次真实写入约 5MB 数据到 `segment.bytes=1MB` 的 topic，直接看磁盘上的文件、用 `kafka-dump-log.sh` 核对文件名的含义，再真实
上一篇看到每个 Segment 旁边都有 `.index` 文件。这次直接用 `kafka-dump-log.sh` 把真实的索引内容读出来，和 `.log` 里每个 batch 的真实位置逐条对照，再手工做一次"查 offset 1200"的定位，看索引到底存了什么、查找是怎么
上一篇的 Offset Index 解决"给定 offset 找位置"，而"给定一个时间点，找到从那时起的第一条消息"靠的是另一份索引：`.timeindex`。这次写入 300 条时间戳每条相隔 1 秒的消息，读出真实的时间索引，再用真实的时间戳查询看结果，最后试探 broke
`retention.ms` 到期，消息就消失了吗？这次把一个 topic 的 `retention.ms` 设成 20 秒，写入 1200 条消息（跨三个 Segment），然后每秒观察一次磁盘目录，记录文件到底在什么时候被改名、什么时候真正从磁盘消失，以及消息还能不能被读到。