做地图类业务这八年，我见过太多人死在 Redis 的 Geo 功能上。这篇文章不整虚的，直接告诉你怎么在真实高并发下，把 Geo 查询做到毫秒级，且绝不崩盘。

先说个真事。去年有个做同城配送的客户，凌晨三点电话打爆我。他们的骑手定位查询延迟飙到 500ms 以上，用户投诉骂街。查了半天，发现他们居然在 MySQL 里存了几百万条经纬度数据，每次查询都全表扫描。这哪是开发，这是给服务器送终。

其实，解决这个问题的核心，就是用好 geo redis 这个利器。

很多新手有个误区，觉得 Redis 快，就随便用。大错特错。Geo 功能底层用的是 ZSET（有序集合），利用的是对数级跳表。如果你不懂它的底层逻辑，稍微不注意，就能把内存撑爆。

咱们聊聊具体的坑。第一个坑，是精度问题。

Redis 的 Geo 存储精度是固定的，大约 0.5 米到 2.5 米之间。对于大多数业务，比如找附近的奶茶店、共享单车，这完全够用。但如果你做的是高精度测绘或者无人机路径规划，千万别直接用 Redis 存原始经纬度，误差会害死人。这时候，你得在应用层做预处理，或者混合使用其他方案。

第二个坑，是过期策略。

很多兄弟喜欢把用户位置直接存在 Redis 里，设个短过期时间。比如，用户每 5 秒上报一次位置，就更新一次。结果呢？内存里全是僵尸数据，查询效率极低。

我的建议是，别存“当前”位置，要存“最近有效”位置。结合业务逻辑，比如用户离开页面超过 10 分钟，就自动清理。或者，用布隆过滤器先判断用户是否在线，再查 Geo。这样能过滤掉 80% 的无效查询。

再说说查询优化。

当你需要查找“半径 5 公里内的所有用户”时，直接用 GEORADIUS 命令。但要注意，这个命令在数据量超过 10 万时，性能会明显下降。为什么？因为它是全量扫描附近的成员。

这时候，就得引入 geo redis 的分片策略。

别把所有数据都塞进一个 Key 里。你可以按城市、甚至按街区，把数据拆分到不同的 Key 中。比如，北京朝阳区的数据放在一个 Key，海淀区的放在另一个。这样，每次查询只扫局部，速度提升不止一点点。

我有个案例，之前处理过某打车平台的热点区域查询。他们把城市划分为 1km x 1km 的网格，每个网格对应一个 Redis Key。当用户发起叫车请求时，先算出用户所在的网格，再查该网格及周边 8 个网格的可用司机。这套方案下来，QPS 从 2000 直接干到了 20000，而且 CPU 占用率不到 10%。

还有一点，很多人忽略的是，Geo 数据不仅仅是用来查附近的。它还可以用来做简单的防作弊。

比如，两个账号在 1 秒内从北京跳到了上海，这显然不正常。你可以定期跑个脚本，检查用户位置变化的速度。如果超过物理极限，直接封号。这招对黑产很管用，而且几乎不消耗额外资源。

最后，提醒一句，监控不能少。

一定要监控 Redis 的内存使用率和慢查询日志。Geo 命令一旦超时，整个服务都可能被拖垮。设置合理的 timeout，加上告警，比事后救火强一万倍。

总之，用 geo redis 不难，难的是根据业务场景做取舍。别迷信万能药，因地制宜才是王道。希望这些踩坑经验，能帮你少走弯路。毕竟，代码是写给人看的，也是写给服务器看的，让它舒服，你才能舒服。