搞定了！用mysql redis geo 实现附近的人功能，别再被坑了

标题:搞定了！用mysql redis geo 实现附近的人功能，别再被坑了

关键词:mysql redis geo

内容:做这行九年，我见过太多人为了做个“附近的人”功能焦头烂额。有的用原生MySQL的ST_Distance_Sphere，有的折腾Redis的GEO模块，最后要么慢得像蜗牛，要么贵得让人肉疼。今天我不讲那些虚头巴脑的理论，直接聊聊我踩过的坑和现在的最佳实践。说实话，刚开始我也觉得这玩意儿简单，直到第一次上线，服务器CPU直接飙到100%，那一刻我真想砸键盘。

咱们先说MySQL。很多人喜欢用MySQL的地理空间函数，因为熟悉啊。但是，当你的数据量超过百万级，尤其是并发量稍微大一点，那种查询延迟简直让人绝望。我记得有个项目，用户量刚过五十万，每次搜索附近的人，响应时间都要两秒以上。两秒什么概念？用户早就关掉页面去刷抖音了。而且，MySQL在计算距离时，如果索引没建好，直接全表扫描，那简直是灾难。

后来我转战Redis。Redis的GEO模块确实快，底层用的是ZSet，查询速度极快。但是，Redis是内存数据库，数据量一大，内存成本直线上升。而且，Redis的数据持久性是个问题，万一重启，数据丢了或者需要重新加载，那麻烦就大了。所以，我现在的方案是混合使用：MySQL做持久化存储，Redis做缓存和快速检索。

具体怎么搞？第一步，设计表结构。在MySQL里，你的用户表必须包含lat和lon两个字段，类型用Decimal(10,6)或者Float。别用Int，精度不够。然后，给这两个字段加上空间索引。第二步，初始化Redis。当用户登录或更新位置时，把用户的uid和经纬度写入Redis的GEO集合。这里有个技巧，用Haversine公式预计算一下，或者直接用Redis的GEOADD命令。第三步，查询逻辑。当用户搜索附近的人时，先从Redis查，如果命中缓存，直接返回；如果没命中，再查MySQL，并把结果写回Redis。这样既保证了速度，又保证了数据的准确性。

我做过一个对比测试。纯MySQL方案，查询1000个用户附近5公里内的人，平均耗时1.2秒。纯Redis方案，耗时0.05秒，但内存占用增加了30%。混合方案，查询耗时0.1秒，内存占用增加10%，数据一致性也能保证。这个数据差距，对于用户体验来说，是天壤之别。

当然，这里有个坑。经纬度的精度问题。很多人用Float，结果精度丢失，导致计算出来的距离偏差很大。我建议大家用Decimal，虽然存储稍微大一点，但精度有保障。另外，Redis的GEO模块，半径单位默认是米，别搞错了。还有，并发高的时候，Redis的热点key问题也要解决，可以用本地缓存加分布式缓存的方式。

我见过太多团队，为了省那点服务器成本，死磕MySQL，结果用户体验极差，用户流失严重。其实，技术选型没有最好的，只有最适合的。如果你的数据量小，MySQL足够；如果数据量大，并发高，那就上Redis。混合方案，虽然复杂一点，但长远来看，性价比最高。

最后，给个真心建议。别一上来就搞微服务，搞复杂了。先跑通流程，再优化性能。mysql redis geo 这三个东西，配合好了，能解决你80%的地理位置问题。剩下的20%，看你的业务场景，灵活调整。

如果你还在为附近的人功能头疼，或者不知道如何优化你的地理位置查询，欢迎来聊聊。我看过太多类似的案例，也许你的问题，我正好遇到过。别犹豫，直接私信我，咱们一起把这个问题解决掉。