做LBS（基于位置的服务）的时候，我最怕听到的声音就是“系统崩了”。上周三凌晨两点，客服群炸锅了，说咱们的新城区域定位失效，用户找不到附近的门店。我爬起来查日志，发现Redis内存爆了，RedisGeo模块的数据量在高峰时段直接打满了主机的带宽。那一刻我知道，光靠堆硬件解决不了问题，得从架构设计上找漏洞。

很多刚入行做位置服务的朋友，喜欢一上来就在Redis里存所有用户的经纬度。这简直是自杀式行为。我有个前同事，为了省事，把所有活跃用户的位置都塞进Redis GEO结构中，结果QPS稍微高一点，整个缓存集群就抖动。要知道，Geo底层是用Zset实现的，虽然它擅长做半径搜索和距离计算，但它不是万能的神器。

我们现在的方案是分层处理。首先，对于实时在线且高频互动的用户，比如外卖骑手或打车司机，我们保留他们的最新坐标在Redis Geo结构中。这部分数据量不大，查询性能也很稳。但对于那些只是偶尔打开App看看附近推荐的用户，绝对不要实时同步他们的位置。我们改用MySQL+PostGIS或者专门的空间数据库进行离线分析，或者定期（比如每小时）更新一次位置信息。这样既减轻了Redis的压力，也保证了数据的准确性。

再说说那个经常被忽视的“过期策略”。在Geo结构中，如果你想让不活跃用户自动下线，必须设置好TTL（生存时间）。但我建议不要把TTL设得太短，否则服务器得不断重设键值，产生大量写操作。我一般设成30分钟，如果用户一直在线，就动态延长；如果下线了，自动失效，不用手动清理。这点很重要，因为手动清理几千几万条数据，对Redis来说是噩梦。

还有一个坑是“圆形搜索”和“矩形搜索”的滥用。Redis Geo原生的georadius命令是搜索圆形的。但在某些业务场景下，比如推送周边的优惠券，矩形搜索其实更实用，也更省算力。如果我们非要在这个圆形结构里搞矩形逻辑，就得把所有用户拉出来算一遍，然后过滤。这效率太低了。我的建议是，如果业务需要矩形范围，结合HBase或者Elasticsearch这类支持空间索引的中间件会更合适，别把Redis当成全能数据库用。

至于价格嘛，说实话，云服务器加上Redis商业版的费用，一个月少说也得大几千。但如果架构设计不合理，流量一来，扩容都来不及，那个损失可比云服务费贵多了。所以，不要觉得省钱就不好好设计架构，后期重构的钱够你买好几台服务器了。

最后，给兄弟们几个实在的建议：

1. 千万别把非实时用户的坐标都塞进Redis Geo，分类管理，冷数据离线处理。

2. 善用过期时间，别手动清理大量数据，让Redis自己搞定。

3. 根据业务场景选工具，圆形用Redis Geo，矩形考虑其他空间数据库或搜索引擎。

4. 压测要做足，特别是峰值流量下的Redis负载情况，别等线上挂了才补救。

如果你也在搞Geo相关的功能，遇到性能瓶颈或者不知道该怎么选型，欢迎随时来聊聊。我们可以一起看看你的架构，或许能帮你省下不少排查问题的时间。别一个人闷头debug了，有时候换个思路，事半功倍。