本机真实用5分片灌入3个高频词和300个长尾词,terms聚合size=3返回doc_count_error_upper_bound=7非零,哪怕top3计数碰巧依然精确。真实把同样数据灌进单分片索引重跑,误差上界精确归零——证明误差根源是多分片各自只上报局部候选词,合并时可能遗漏,不是terms聚合本身不精确。
真实对比fetch.min.bytes=1和1MB两种配置,验证凑批门槛和等待超时(fetch.wait.max.ms)谁先满足谁说了算。
写10000条只消费提交3000条,验证LAG精确等于LOG-END-OFFSET减CURRENT-OFFSET=7000。
制造一个处理速度比生产慢3倍的consumer,验证LAG持续单调上涨(18秒内5611→30398)是结构性问题的信号。
验证segment.bytes最小值1MB的硬性限制,写入20000条消息观察磁盘真实切出4个约999807字节的segment文件。
用top命令真实测量186.37MB/秒持续写入下broker的CPU占用,发现全程低于2%,瓶颈不在broker。
对比读取老数据、新数据、老数据复读三种场景的延迟,验证page cache命中带来约2倍的速度提升。
验证新broker加入不会自动均衡已有数据,用kafka-reassign-partitions.sh --generate生成真实用上新broker的分配方案。
真实验证减少分区数被拒绝(InvalidPartitionsException),增加分区数则立刻成功。
用SIGTERM依次优雅重启全部3个broker,验证幂等producer+acks=all组合下2059条消息0丢失0重复。
真实追踪topic删除后磁盘目录先被重命名标记,65秒后(超过file.delete.delay.ms=60000)才真正被物理擦除。
发5条订单其中2条构造成非法数据,验证DLQ模式如何隔离失败消息同时不阻塞主流程offset推进。