本文关键词：es geo distance

干这行十一年了，说实话，每次看到新人拿着官方文档里那个简单的 geo_point 例子去生产环境跑，我就想笑。那玩意儿在测试环境里确实快，可一旦数据量上来，或者并发稍微高一点，你的集群直接给你表演一个原地爆炸。今天不整那些虚头巴脑的理论，就聊聊我在一线踩过的坑，还有怎么让 es geo distance 真正跑起来。

先说个真事。去年有个做本地生活的项目找我救火，老板说我们要搞“附近的人”，要求5公里内毫秒级返回。结果上线第一天，查询接口直接超时，CPU 飙到 100%。我进去一看，好家伙，人家直接在查询语句里用了大量的 script 去算距离，还开了多核并行。这哪是查数据，这是在算数竞赛啊。

记住，es geo distance 的核心不是“算”，而是“筛”。

第一步，建索引的时候，别偷懒。很多新手为了省事，把经纬度存成 double 类型，然后自己写脚本算。这是大忌！必须用 geo_point 类型。而且，如果你做的是国内业务，记得用 GCJ-02 坐标系，别直接用 WGS-84，否则你查出来的“附近”，可能是在海里或者隔壁省。这点我吃过亏，当时为了省事儿没转换，导致用户投诉说离得近却查不到，排查了三天才发现是坐标系偏差，那几天头发都掉了一把。

第二步，分片策略要讲究。geo 类型的查询对分片非常敏感。如果你的数据量很大，建议按行政区划或者业务区域来分片，而不是随机分片。这样在查询某个特定区域时，可以跳过不相关的分片，性能提升不止一点点。我之前的一个项目，通过优化分片策略，将查询延迟从 200ms 降到了 20ms 以内。

第三步，查询语句怎么写？别用 match_all 然后过滤。要用 geo_distance 或者 geo_bounding_box。geo_bounding_box 适合矩形区域，比如“朝阳区范围内”，速度快；geo_distance 适合圆形区域，比如“我周围5公里”。注意，geo_distance 有个参数叫 distance_type，默认是 arc，更精确但稍慢；如果是精度要求不高，可以用 plane，速度更快。这个细节，官方文档里写得含糊其辞，只有踩过坑的人才懂。

还有，别忽视缓存。es 的 query cache 对 geo 查询效果有限，因为每次查询的距离和中心点可能都不同。这时候，你得考虑应用层缓存。比如，把热门区域的查询结果缓存到 Redis 里，设置一个合理的过期时间。我见过有人把“北京朝阳区附近1公里”的结果缓存一天，结果第二天天气变了，用户还是收到昨天的推荐，这体验简直烂透了。

最后，监控不能少。开启 es 的 slow log，设置合理的阈值，比如 1 秒。一旦有查询超过这个时间，立马报警。别等用户投诉了才去查日志，那时候黄花菜都凉了。

说实话，es geo distance 这东西，看似简单，实则深坑无数。从数据预处理、索引设计、查询优化到缓存策略，每一步都得小心翼翼。你要是只盯着官方文档看，迟早被坑得怀疑人生。

如果你也在搞类似的项目，或者遇到了查询慢、数据不准的问题，欢迎来聊聊。别自己瞎折腾了，有些坑，别人踩过了，你就不用再跳一遍。毕竟，时间就是金钱，头发也是。