别被ES geo 均匀分布骗了，数据倾斜才是你集群崩盘的元凶

上周三凌晨三点，报警群炸了。某头部物流平台的轨迹查询接口响应时间从200毫秒飙升到8秒。运维老张满头大汗地盯着Kibana，发现几个主分片负载高达95%，而其他分片却在摸鱼。这不是玄学，这是典型的地理数据分布不均导致的“热点”问题。

很多刚接触Elasticsearch的朋友，听到“地理空间查询”就兴奋，觉得存点经纬度很简单。但一旦数据量上到千万级，甚至亿级，你会发现，默认的哈希路由根本不管你的业务逻辑。如果你还在盲目追求所谓的es geo 均匀分布，那可能正在给自己挖坑。

真实情况是，地理数据天生就不均匀。人类住在城市，不在太平洋中心。你的用户数据集中在北上广深，而你的集群节点分布在全国各地。这时候，如果你指望ES自动帮你把数据打得像撒胡椒面一样均匀，那纯属做梦。

我见过一个真实案例。一家做共享单车的公司，把全中国的单车位置数据存入ES。他们设置了5个主分片，采用默认的哈希算法。结果呢？北京地区的请求量占到了总流量的40%，但因为哈希算法的特性，这些北京的数据并没有均匀分散到5个节点上，而是集中在了两个节点。另外三个节点闲着没事干，两个节点CPU常年100%。这就是典型的“数据倾斜”。

这时候，有人会说，那我手动指定文档ID不就行了？比如用经纬度取整作为ID。这确实能解决一部分问题，但引入了新的麻烦。如果你的业务需要按城市聚合，或者按区域过滤，这种硬编码的ID策略会让查询变得极其复杂。而且，一旦城市边界调整，或者新增城市，你的ID策略就得改，维护成本极高。

真正的解法，不是追求绝对的es geo 均匀分布，而是追求“业务感知”的均匀。我们需要引入一种更智能的分片策略。比如，使用Geo Hash作为文档ID的一部分。Geo Hash将二维的经纬度转换为一维的字符串，相邻的区域会有相似的哈希值。这样，地理位置相近的数据会被路由到相近的分片，既保证了局部查询的高效，又在一定程度上缓解了热点。

但要注意，Geo Hash也有缺陷。当精度越高，分片数量呈指数级增长，小分片太多，集群管理压力巨大。我之前的一个项目里，把Geo Hash精度设到了7位，结果集群里有上千个小分片，Master节点的压力大到无法承受。后来我们调整到6位，并配合自定义的分片函数，才把性能稳住了。

还有一个容易被忽视的点：写入压力。地理数据的写入通常是高频的。如果大量数据同时写入同一个分片，不仅会导致该分片负载过高，还会引起频繁的刷新（Refresh），导致搜索延迟增加。这时候，你需要调整index.refresh_interval参数，或者使用批量写入（Bulk API），并合理设置批量大小。我测试过，对于地理数据，批量大小设置在500-1000之间，性能提升最明显。

别迷信那些所谓的“最佳实践”。没有放之四海而皆准的参数。你的数据分布是什么样的，你的查询模式是什么样的，决定了你的优化方向。如果你发现某个分片特别热，不要急着加节点，先看看是不是路由算法出了问题。有时候，换个分片策略，比加机器管用得多。

最后说一句，es geo 均匀分布是个伪命题。你要的是“可控的分布”，而不是“均匀的分布”。理解你的数据，理解你的查询，比盲目追求技术指标更重要。毕竟，系统是为业务服务的，不是为指标服务的。下次再遇到查询慢，别急着扩容，先查查数据是不是“扎堆”了。这才是解决问题的正道。