京公网安备11010502063487号Topic 是业务上的一个消息分类，Partition 是它的分片，Replica 是每个 Partition 的副本。这三层关系容易背下来，但"副本会不会一起挂、一起切换"这种问题只有真实杀一个 Broker 才能看清楚。这次在真实的 3 节点集群上建了一个 6 分区、3 副本
一条消息发出去，最终落在哪个分区，取决于三种情况：有 key（按 key 哈希）、显式指定分区号（跳过一切计算）、都没有（交给分区器决定）。这次用真实的 Java 客户端、真实控制批次大小，把"没有 key 时到底怎么选分区"这件事测清楚。
如果 Producer 每条消息都单独发一次网络请求，吞吐量会被请求数量本身卡死。Kafka 客户端会把发往同一个分区的消息攒成一个 RecordBatch 再一起发送。这次真实对比了"几乎不攒批"和"正常攒批"两种配置，用真实耗时把差距量化出来。
默认分区器只认哈希值，不认业务含义——想让特定一类消息独占某个分区（比如给高优先级订单单独留一个分区，方便下游优先处理），光靠 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` 核对文件名的含义，再真实