上周二，凌晨两点，线上告警群炸了。
我的心跳也跟着加速。
项目是个LBS社交应用，核心功能就是“附近的人”。
之前为了赶进度，架构师拍板说，直接用 Redis 的 Geo 模块。
听起来很美好，对吧？
代码也就几行。
GEOADD 存入坐标，GEORADIUS 查询附近的人。
简单，粗暴，有效。
刚开始上线那半个月，一切风平浪静。
日活也就几千，服务器负载低得让人想睡觉。
直到那个周五晚上，运营搞了个大型线下活动。
流量瞬间飙升了十倍。
也就是那一刻，问题爆发了。
CPU 直接飙到 95%。
Redis 响应时间从几毫秒变成了几百毫秒。
用户打开页面，转圈圈转得想砸手机。
我盯着监控屏幕，满头大汗。
为什么？
明明 Redis 官方文档说，Geo 是基于 Sorted Set 实现的，性能应该没问题啊。
后来复盘才发现，是我们对 geo hash redis 的理解太浅了。
很多人以为，只要用了 Redis，就万事大吉。
其实，Geo Hash 算法本身是有缺陷的。
它把二维的经纬度，压缩成一维的字符串。
这个字符串，就是排序的依据。
问题出在边界效应上。
假设两个人，一个在哈希格的左上角，一个在右下角。
虽然他们物理距离很近，可能只有几十米。
但因为跨过了网格边界，他们的 Geo Hash 值可能天差地别。
在 Sorted Set 里，这两个值离得十万八千里。
当你查询“附近的人”时，Redis 需要扫描的范围变大。
扫描范围一变大，计算量就指数级上升。
这就是为什么流量一大，Redis 就崩。
我们当时的查询半径设得太大，动不动就查 50 公里。
对于 50 公里内的所有点，Redis 都要做距离计算和排序。
这在单机 Redis 上，根本扛不住。
解决办法是什么？
不是换数据库，而是优化策略。
我们引入了多级缓存和预计算。
首先，把大半径查询拆分成小网格。
利用 geo hash redis 的特性，先查当前网格，再查周边 8 个网格。
这样，每次扫描的数据量就小多了。
其次，对于高频热点区域，我们做了本地缓存。
Redis 只负责存储和基础计算，复杂的聚合逻辑下沉到应用层。
改动不大，但效果立竿见影。
CPU 降到了 30% 以下。
响应时间恢复到了毫秒级。
这次事故让我明白，技术选型没有银弹。
geo hash redis 确实好用，但它不是万能的。
你得懂它的底层逻辑。
你得知道它在什么场景下会失效。
比如，当用户分布极度不均匀时。
或者当查询半径动态变化极大时。
这时候，单纯的 Geo 命令可能就不够看了。
我们需要结合业务场景，做更细致的分层。
比如，同城用户用 Geo，跨城用户用倒排索引。
别迷信框架，别迷信工具。
真正懂技术的人，是那些知道工具哪里会卡壳的人。
现在的系统稳定多了。
偶尔还有小波动，但都在可控范围内。
每次看到监控曲线平稳，心里就踏实。
这也算是技术人的小确幸吧。
如果你也在用 Redis 做 LBS 相关功能。
建议你多看看 Geo Hash 的边界案例。
别等到线上报警了，才想起来去查文档。
那时候，后悔都来不及。
分享这些，不是为了显摆。
是想告诉后来者，坑我都踩过了。
你可以少走弯路。
毕竟，生活已经够累了，代码就别再给自己挖坑了。
保持敬畏，保持学习。
这才是程序员该有的样子。
希望这篇 geo hash redis 的避坑记录，能帮到你。
如果有类似的问题，欢迎在评论区聊聊。
我们一起交流，一起成长。
技术这条路，从来都不是单打独斗。
共勉。
