很多刚入行或者对Redis不太熟的朋友，一听到“地理围栏”、“附近的人”就头大，觉得这是高深莫测的算法。其实，Redis Geo的核心就干一件事：把经纬度存起来，然后极速算距离和范围。如果你正在纠结redis geo干什么用，这篇文章能帮你彻底理清思路，避开那些花里胡哨却不好用的坑。
先说个大实话，我在这行摸爬滚打八年，见过太多项目因为盲目上Redis Geo而翻车。最典型的就是那种“附近的人”功能，用户量一旦上来，Redis内存爆满，查询延迟飙升，最后只能拆库。Redis Geo底层其实是用的ZSet（有序集合），它把经纬度通过GeoHash算法转换成一个64位的整数，然后利用ZSet的排名特性来快速查找。这听起来很美好，但实际操作中，细节决定成败。
举个真实的案例。去年有个做同城配送的客户，想搞一个“骑手周边3公里内订单推送”的功能。他们一开始觉得简单，直接调用Redis的GEOADD和GEORADIUS。结果上线第一天，晚高峰高峰期，Redis CPU直接飙到90%以上，订单推送延迟高达2秒。为啥？因为GEORADIUS在数据量大时，是全表扫描式的近似计算，效率极低。这时候你就得明白，redis geo干什么用？它适合做小范围、高频次的实时查询，而不是大规模的历史轨迹存储。
解决这个问题的办法，不是换数据库，而是优化策略。我们当时调整了方案，把“实时推送”和“历史轨迹”分开。实时位置更新，只保留最近一次坐标，利用Redis的过期时间自动清理旧数据，减少内存占用。对于历史轨迹，直接扔进MySQL或者MongoDB，按天分表。这样Redis只负责“谁在附近”，不负责“去过哪”。经过这套优化，查询延迟降到了50毫秒以内，内存成本降低了40%。
这里要特别强调一个容易被忽视的点：精度问题。Redis Geo默认使用的是WGS84坐标系，也就是我们常说的GPS标准坐标。但如果你用的是百度地图或者高德地图的坐标，直接存进去，算出来的距离全是错的！我当时为了这个坑，跟开发团队吵了一架。必须要在应用层做一次坐标转换，把GCJ-02或BD-09转成WGS84再存入Redis。这一步不做，后面全是白搭。
另外，关于redis geo干什么用，还有一个高频场景是“签到”或“打卡”。比如公司想统计员工每天在哪些门店打卡。这时候可以用Redis的Set集合配合Geo，先判断是否在范围内，再记录打卡时间。注意，不要每次打卡都去算距离，太浪费资源。只要判定在围栏内，就标记为“有效”，距离计算可以放在离线分析阶段，用Python或者Spark跑批处理。这样Redis的压力会小很多。
我还见过有人试图用Redis Geo做城市级别的热点分析，比如统计北京市内哪个区域用户最多。这种需求，Redis Geo完全不适合。因为它的粒度太细，计算量大。这时候应该用Elasticsearch或者专门的GIS数据库，比如PostGIS。Redis Geo的优势在于“快”和“近”，而不是“全”和“远”。你要清楚它的边界，别拿着锤子找钉子，什么都是钉子。
最后，给点实在建议。如果你现在的系统里，用户量在百万级以下，且对实时性要求极高，Redis Geo是个不错的选择。但一定要做好监控，关注内存使用率和查询耗时。如果数据量超过千万，或者需要复杂的空间分析（比如多边形相交、面积计算），请果断放弃，转向专业的空间数据库。别为了用而用，技术选型是为了业务服务，不是为了炫技。
如果你还在为地理位置相关的性能瓶颈头疼，或者不确定你的场景是否适合用Redis Geo，欢迎随时来聊聊。我们可以一起看看你的具体数据量和并发情况，给个更落地的方案。毕竟，踩过的坑多了，也就知道怎么避开了。
