Scanner 设置了副本选择策略为 CLOSEST_REPLICA，同一张表各个 tablet 大小以及在各个 Tserver 上的分布基本均衡，但依然存在读不均衡的情况。通过 scanner_bytes_scanned_from_disk指标发现三个副本所在的 Tserver 中，其中一个 Tserver 上该指标 value 为 0，即没有任何读请求发送到该 Tserver。读不均衡就会导致 CPU 等指标不均衡（虽然 Kudu 是存储引擎，但是依然有 predicate、懒物化、解压缩等操作需要消耗 CPU），CPU 不均衡就容易造成集群不稳定，Kudu 进程反复重启。
这是因为同一个 client 即使随机，选择的也是同一个 Tserver，并不是读请求随机到全部（3个） Tserver 上。这样做也是考虑了缓存亲和性，即尽量让同一份数据只缓存在一个 Tserver 上，避免了缓存重复（没有使用分布式缓存框架，block cache 只能在 Tserver 本地内存中访问）。
另外两个 Tserver 上scanner_bytes_scanned_from_disk的值都在变大，是因为有多个进程即多个 Kudu Client 在访问这个 tablet，但是也都只随机命中了这两个 Tserver。如果只有一个进程（且 Client 单例），理论上只会有一个 Tserver 读流量会发生变化。
找到主要的读 Kudu 进程，考虑如下场景：有 4 个进程即 4 个 Client，8 个 tserver，进程刚启动的时候进程1-4 的读请求分别被随机到 Tserver1-2 / Tserver3-4 / Tserver5-6 / Tserver7-8。如果进程 3 中的消费者被 Kafka 踢掉，Kafka topic 分片被 rebalance 到另外三个进程中，这个时候全部的读请求都会通过对应的 3 个 Client 发送，即 Tserver5-6 不会再有任何读请求，进而导致读不平衡。
重启之后 Tserver 之间读流量明显变的平衡，所以需要解决的问题就变成了：如何减少或避免消费者被 Kafka 踢掉。
