1. Key 经过 Murmur2 → 取模 → 落到某个 Partition
输入一个 Key，看它在不同分区数下分到哪个分区。下方柱状图显示「这一批 Key 在各分区的分布」，红色柱 = 热点分区（流量 > 平均 ×1.5）。
点上面的 Key 输入框试试看。
分布柱状图
正常分区
热点分区（> avg ×1.5）
| 指标 | 值 | 解读 |
|---|---|---|
| 分区数 | - | — |
| 消息数 | - | — |
| 最热分区比例 | - | 理想 ≈ 1/N |
| 最冷分区比例 | - | 理想 ≈ 1/N |
| 变异系数 CV | - | ≤ 0.1 良好；> 0.3 失衡 |
2. 分区数 N 与「吞吐 / Rebalance 时间 / Controller 元数据」的权衡
拖动「单 Topic 分区数」，观察右侧三条曲线：吞吐先升后降（batch 凑不满）、Rebalance 时间线性涨、元数据条目线性涨。
预估生产吞吐
-
MB/s
Rebalance 时间
-
ms
Controller 元数据
-
条目
三条曲线（X 轴 = 分区数 1~200）
吞吐（MB/s）
Rebalance 时间（ms）
Controller 元数据条目（×100）
3. 加分区前后，同一 Key 的落点会不会变？
这就是「为什么加分区是破坏性操作」的核心证据。下面随机抽 30 个 Key，对比 N₁ → N₂ 后的落点变化。
变化的 Key 数
-
不变的 Key 数
-
变化率
-
分区数 = N₁（前）
分区数 = N₂（后）
4. RF / min.insync.replicas / acks 的故障行为表
调整 RF 和 min.isr，模拟「N 台 Broker 宕机」时的写入结果。
点击「模拟」查看结果
完整故障矩阵
| RF | min.isr | acks | 挂 1 台 | 挂 2 台 | 挂 RF-1 台 | 挂 RF 台 |
|---|