干了11年Geo行业，从最早的GPS手持机到现在的LBS大数据平台，我见过太多人把Redis的Geo功能用废了。很多人一听到“附近的人”、“同城配送”、“门店引流”，第一反应就是Redis。觉得快，觉得简单。但真上手了，坑多得让你怀疑人生。

今天不扯虚的，就聊聊redis支持geo 到底该怎么玩，以及那些官方文档里不会告诉你的真实成本。

先说结论：Redis Geo 适合做轻量级、实时性要求高、数据量在百万级以内的场景。如果你要做千万级以上的精准地理围栏分析，或者需要复杂的轨迹回放，趁早换方案。别为了炫技把数据库搞崩了。

我见过最惨的一个案例，某生鲜电商用Redis Geo 存了500万用户的实时位置。结果呢？内存直接爆满，服务器每天重启三次。为什么？因为他们没算过账。

Redis Geo 底层用的是GeoHash，把经纬度压缩成一个字符串。这个字符串越长，精度越高，占用的内存也越多。默认精度下，一个坐标大概占100多字节。500万个坐标，光存数据就要几百兆，加上索引、集群开销，轻松突破几个G。对于小团队来说，这笔钱花得冤枉。

对比一下MySQL。MySQL 5.7+ 也支持空间索引，虽然查询速度比Redis慢个几倍，但存储成本低得多。如果你的业务对实时性要求没那么变态，比如只是每小时更新一次用户位置，MySQL完全够用。别一上来就搞高并发，那是给有钱人准备的。

再说价格。云厂商的Redis实例，内存价格是硬伤。以阿里云为例，4G内存的Redis实例，一个月大概几百块。如果你需要16G，价格直接翻四倍。而同样存储量的MySQL实例，可能只要几十块。这就是为什么很多初创公司死在Redis上——流量起来了，账单也吓死人。

避坑指南来了。

第一，别存历史轨迹。Redis是内存数据库，主打一个“快进快出”。如果你想记录用户过去一个月的行走路线，请存到ClickHouse或ES里。Redis只存最新位置，或者最近N个点。

第二，注意精度问题。GeoHash的精度是固定的，你不能随意调整。如果你需要米级精度，可能需要自定义算法，或者用其他方案。默认的GeoHash精度大概在100米左右，对于打车软件够用，但对于外卖配送，可能有点糙。

第三，并发写入要控制。虽然Redis单线程处理命令很快，但Geo的添加和查询都涉及复杂的位运算。如果每秒写入量超过1万，建议加缓冲队列，别直接怼到Redis上。

我最近帮一家连锁咖啡店做选址分析，客户想用Redis Geo 找附近的竞品。我劝他别用。因为竞品的数据是静态的，不需要实时性。我用PostGIS做了个空间查询，查询速度虽然慢点，但能一次性跑出半径5公里内的所有竞品，还能分析人口密度。这才是正道。

所以，redis支持geo 并不是万能的。它只是工具箱里的一把锤子，不是所有问题都是钉子。

最后给点真心建议。

如果你的日活用户超过100万，或者需要毫秒级的响应，Redis Geo 值得考虑。但一定要做好容量规划，预留30%的内存冗余。

如果你的业务还在起步阶段，或者数据量不大，先用MySQL空间索引练手。成本低，容错率高。

别盲目追求技术栈的先进性。适合业务的，才是最好的。

我是老张，做了11年Geo，踩过无数坑。如果你还在纠结选什么数据库，或者Redis Geo 用得不顺手，欢迎来聊。咱们不整那些虚头巴脑的，直接说问题，给方案。

记住，技术是为业务服务的，别让它成为你的负担。

本文关键词：redis支持geo