京公网安备11010502063487号用kafka-reassign-partitions.sh把卡着死亡broker的分区真实迁移到健康broker上，--execute和--verify两步真实完成ISR从残缺恢复到健康。
验证broker故障恢复后leader不会自动切回preferred副本，用kafka-leader-election.sh一条命令真实修正了集群里累积的8个分区不均衡。
持续写入30万条消息制造压力，用kafka-log-dirs.sh验证leader和两个follower磁盘字节数真实完全同步，offsetLag始终为0。
对运行中的broker做jcmd线程转储，真实数出每个监听端口3个网络线程(对应num.network.threads=3)和共享的8线程请求处理池(对应num.io.threads=8)。
真实验证os.sendfile()要求目标必须是socket，用500MB数据对比sendfile和read+send两种方式，真实测得sendfile快1.29倍。
用producer-perf-test真实测batch.size=1到默认值带来51倍吞吐提升，而acks=1相对acks=all在同样批量下只快5%，揭示批量大小才是主要瓶颈。
用同样稀疏的消息到达节奏对比linger.ms=0和20，网络请求数真实从1973降到246，总耗时几乎不变，验证linger.ms近乎免费的批量收益。
用同一份重复性日志真实对比5种压缩方式的磁盘占用和吞吐量，gzip压缩率最高但较慢，zstd在压缩率和速度之间取得最好平衡。
Kafka 事务能让一个 Producer 对多个 Topic/Partition 的写入要么全部提交、要么全部不可见。这次真实用一个事务型 Producer 往两个 Topic 各写一条消息，分别验证提交和中止之后 read_committed/read_uncommitted 两种隔离级别看到的内容有什么不同；中途还真实撞见一个容易漏掉的细节：中止事务时如果消息还没真正发到 Broker，客户端会直接把它悄悄丢弃，不会留下任何痕迹。
Topic 是业务上的一个消息分类，Partition 是它的分片，Replica 是每个 Partition 的副本。这三层关系容易背下来，但"副本会不会一起挂、一起切换"这种问题只有真实杀一个 Broker 才能看清楚。这次在真实的 3 节点集群上建了一个 6 分区、3 副本
一条消息发出去，最终落在哪个分区，取决于三种情况：有 key（按 key 哈希）、显式指定分区号（跳过一切计算）、都没有（交给分区器决定）。这次用真实的 Java 客户端、真实控制批次大小，把"没有 key 时到底怎么选分区"这件事测清楚。
如果 Producer 每条消息都单独发一次网络请求，吞吐量会被请求数量本身卡死。Kafka 客户端会把发往同一个分区的消息攒成一个 RecordBatch 再一起发送。这次真实对比了"几乎不攒批"和"正常攒批"两种配置，用真实耗时把差距量化出来。