做LBS（基于位置的服务）这行，谁没被“附近的人”查询慢哭过？

我刚入行那会儿，公司用的是MySQL的GeoHash方案。那时候数据量小，还凑合能用。但到了日活百万级，每次用户打开APP，后端就要去扫表、算距离、排序。高峰期数据库CPU直接飙到90%，运维大哥天天在群里骂娘。后来我们接入了Redis的Geo功能，配合Lua脚本做原子操作，查询速度从秒级降到了毫秒级。这中间的坑，我踩过不少，今天掏心窝子跟大家聊聊，怎么用最接地气的方式搞定高性能定位。

很多新人有个误区，觉得Redis Geo就是简单的存储经纬度。其实不然，Redis底层用的是GeoHash算法，把二维的经纬度映射成一维的字符串。这就好比把地图折成了一条线，距离近的点，前缀相似。但这里有个大坑：如果你直接调用Redis原生的GEORADIUS命令，在高并发下，这个命令会阻塞Redis主线程。一旦阻塞，整个服务都可能卡死。

所以，真正的解法是：Redis Lua Geo。

第一步，明确业务场景。别为了炫技而用。如果你的业务只是简单的“附近5公里店铺”，那Redis Geo足够。但如果你需要“附近5公里且评分大于4.5的店铺”，这时候单靠Redis不行，得结合Lua脚本。Lua脚本的核心优势是原子性，它能把“查询+过滤+排序”打包成一个整体，在Redis内部执行，避免多次网络IO和并发竞争。

第二步，编写Lua脚本。这是最考验功底的地方。别指望网上抄个模板就能跑。你得理解Redis的KEY和ARGV。比如，我们要查某用户附近的餐厅。脚本逻辑大致是：先获取用户经纬度，计算GeoHash前缀，然后遍历附近的Hash桶，取出候选ID，最后在Lua内部进行距离计算和过滤。注意，Lua脚本里不要做复杂的数据库查询，只处理内存数据。

这里有个真实案例。我们之前有个外卖平台，高峰期每秒并发请求超过2000次。原本用Java代码循环调用Redis，响应时间波动极大，有时甚至超过2秒。改成Lua脚本后，我们将查询逻辑封装在一个脚本里，每次请求只发送一次命令。结果呢？P99延迟从1.8秒降到了15毫秒。数据不会骗人，这就是性能的提升。

第三步，处理边界情况。GeoHash有个天然缺陷：在赤道附近精度高，在两极附近精度低。而且，圆形区域查询可能会漏掉角落的点，或者包含远处的点。这时候，你需要在Lua脚本里做二次过滤。比如，先查一个大圆，拿到结果后，再用精确公式（如Haversine公式）在Lua里重新计算距离，剔除不需要的点。虽然Lua执行计算比C慢，但比起网络往返，这点开销可以忽略不计。

第四步，监控与优化。上线后，一定要监控Redis的慢查询日志。如果发现Lua脚本执行时间超过10毫秒，说明脚本太复杂了。这时候要考虑拆分逻辑，或者优化GeoHash的层级。另外，记得设置脚本的缓存，Redis会自动缓存Lua脚本，但你要确保脚本内容不变，否则会导致缓存失效，影响性能。

最后，说说心态。做技术，别总想着一步到位。Redis Lua Geo不是银弹，它适合读多写少、对实时性要求高的场景。如果你的数据量极大，或者需要复杂的地理空间分析，还是得回到PostGIS或者Elasticsearch。但大多数互联网场景，Redis Lua Geo足够优雅且高效。

记住，代码是写给人看的，顺便给机器执行。写Lua脚本时，注释要清晰，变量名要易懂。别搞那些花里胡哨的缩写，半年后你自己都看不懂。技术选型没有最好，只有最合适。希望这篇干货能帮你少走弯路，早点下班。

本文关键词：redis lua geo