本文关键词：geo es性能
凌晨两点，办公室的空调嗡嗡作响，我盯着屏幕上那根红色的延迟曲线，心里像被猫抓一样难受。就在半小时前，我们的地理围栏查询接口彻底挂了。不是那种偶尔卡顿，而是直接504 Gateway Timeout。对于做LBS（基于位置的服务）团队来说，这简直就是一场灾难。用户打不开APP，老板在群里疯狂@我，那种窒息感，我现在想起来后背还冒冷汗。
事情是这样的，我们最近接入了一个百万级的POI数据，打算做一个“附近的人”功能。起初，我觉得这有啥难的？Geo ES性能不是早就成熟了吗？随便搭个集群，建个索引，搞定。结果现实给了我一记响亮的耳光。
刚开始测试的时候，数据量不大，查询速度快得飞起。我甚至有点飘，跟同事吹牛说这方案稳如老狗。直到那天晚上，模拟并发量上来，QPS到了5000，问题爆发了。你会发现，随着数据量的增加，Geo ES性能急剧下降。原本几百毫秒的查询，变成了好几秒。更离谱的是，CPU占用率直接飙到100%，集群开始抖动，其他业务也跟着受影响。
我查了半天的文档，试了各种参数优化。shard数量调大？不行，小文件太多。调小？合并又太慢。经纬度精度设置？高了内存爆炸，低了精度不够。那几天我几乎没怎么睡觉，眼睛熬得通红，咖啡当水喝。
后来，我们不得不重新审视架构。发现之前的错误在于，我们把所有数据都塞进了一个巨大的索引里，而且没有做好冷热分离。对于热点区域的查询，我们采用了预计算的方式，把常见的地理围栏结果缓存到Redis里，而不是每次都去ES里硬算。这一步改变，让查询速度提升了十倍不止。
还有一个坑，就是Mapping的设计。很多人不知道，Geo ES性能不仅取决于硬件，更取决于你的Mapping。如果你用了默认的text类型去存经纬度，那简直就是自杀。必须用geo_point类型，而且要注意坐标系的一致性。我们之前混用了WGS84和GCJ02，导致查询结果偏差几百米，用户投诉都炸了锅。
现在，我们的系统稳定了。虽然偶尔还会有小波动，但整体可控。回想这段经历，我真的感慨万千。技术这东西，真的没有银弹。所谓的“高性能”，都是在一遍遍踩坑、一次次优化中磨出来的。
我想说的是，别轻信那些“开箱即用”的宣传。当你面对海量的地理数据时，一定要做好压力测试。不要等到线上出问题了才想起来优化。Geo ES性能是一个系统工程，从硬件选型、集群规划，到索引设计、查询优化，每一个环节都不能马虎。
今晚，我终于能早点下班了。走在回家的路上，看着城市的霓虹灯，突然觉得那些闪烁的光点，就像一个个坐标，连接着这个庞大的世界。虽然过程很痛苦，但看到系统恢复平稳的那一刻，那种成就感，真的无可替代。
希望我的这些血泪教训，能帮到正在踩坑的你。如果你也在为Geo ES性能头疼，不妨停下来，检查一下你的Mapping和索引结构。也许，问题就出在最不起眼的地方。
（配图：一张深夜办公室的照片，屏幕上显示着监控仪表盘，红色的警告灯闪烁。ALT: 深夜监控地理查询延迟飙升的报警界面）
