Redis GEO 附近门店查询实战：坐标写入、半径检索和距离排序

很多本地生活、配送、门店预约系统都会遇到同一个需求：用户打开页面后，希望看到“离我最近”的门店列表。这个需求看起来只是排序，实际会涉及坐标存储、半径筛选、距离返回、分页展示和数据更新。

Redis GEO 很适合承接这类高频读场景。它把经纬度和业务成员写入一个有序集合底层结构中，查询时可以按坐标点做半径范围检索，再返回距离和成员信息。本文用“附近门店”做例子，完整走一遍写入、查询和上线注意点。

适合人群

本文适合已经会使用 Redis 基础命令，并准备在业务里实现附近门店、附近设备、附近充电站、附近服务网点查询的开发者。示例用 redis-cli 展示命令，应用层可以按同样思路封装到 Go、PHP、Java 或 Python 服务中。

目录

• 为什么附近查询不建议只靠数据库排序
• 门店坐标如何写入 GEO 索引
• 按用户位置做半径检索和距离排序
• 分页、缓存和门店资料怎么组合
• 常见坑位和上线建议
• 总结

为什么附近查询不建议只靠数据库排序

如果门店数量很少，把所有门店从数据库查出来，再在应用层计算距离，确实可以工作。但当门店规模变大、用户请求变多时，这个方式会带来三个问题。

第一，数据库需要频繁扫描候选门店；第二，应用层要反复计算距离；第三，分页时还要保证距离顺序稳定。Redis GEO 的价值就在这里：先用地理索引快速缩小范围，再把结果交给业务层补齐门店资料。

门店坐标如何写入 GEO 索引

先设计一个专门保存门店位置的 key，例如按城市拆分，减少单个集合过大。

# key 形态：geo:store:{city_id}
# member 建议放门店 id，详细资料仍放数据库或普通缓存
GEOADD geo:store:hangzhou 120.1551 30.2741 store:1001
GEOADD geo:store:hangzhou 120.1688 30.2500 store:1002
GEOADD geo:store:hangzhou 120.1189 30.2866 store:1003

注意 GEOADD 的参数顺序是“经度、纬度、成员”。经纬度顺序写反是附近查询最常见的问题之一，通常会表现为结果为空，或者距离明显不对。

实际业务里，门店资料更新时可以把位置写入 Redis，同时保留数据库里的经纬度作为最终数据来源。Redis 负责高频查询，数据库负责可靠保存和后台校正。

按用户位置做半径检索和距离排序

用户打开页面后，前端通常会提交当前位置经纬度。服务端拿到坐标后，可以用 GEOSEARCH 查询半径内门店，并带上距离。

# 查询用户附近 3 公里内的门店，返回距离，按近到远取前 10 个
GEOSEARCH geo:store:hangzhou \
  FROMLONLAT 120.1600 30.2600 \
  BYRADIUS 3 km \
  WITHDIST \
  ASC \
  COUNT 10

如果 Redis 版本较旧，也可能看到 GEORADIUS 命令。新项目建议优先使用 GEOSEARCH，表达更清晰，也更容易扩展矩形范围查询。

查询结果里通常只有成员和距离。也就是说，Redis 负责告诉你“哪些门店近、距离多少”，门店名称、营业状态、封面图、标签等资料仍应从数据库或门店详情缓存里补齐。

分页、缓存和门店资料怎么组合

附近门店列表一般不建议做很深的分页。更实用的方式是先按半径取一批候选结果，例如 50 个或 100 个，再在应用层结合营业状态、库存、配送范围做二次过滤。

用户坐标
  -> Redis GEO 查附近 100 个门店
  -> 批量读取门店详情缓存
  -> 过滤不可用门店
  -> 按距离和业务权重排序
  -> 返回当前页

如果某个城市访问量很高，可以对“热门地标附近”的查询结果做短时间缓存，例如 30 秒到 2 分钟。缓存 key 不要直接使用完整经纬度，可以先把坐标做网格化，避免同一片区域产生大量相似 key。

常见坑位和上线建议

1. 经纬度顺序写反

GEOADD 和 GEOSEARCH 里都是先经度再纬度。建议接口参数命名使用 lon、lat，而不是 x、y 这类容易混淆的字段。

2. 半径设置过大

半径越大，候选结果越多。附近门店通常可以从 1 公里、3 公里、5 公里逐步兜底，而不是一开始就查几十公里。

3. 成员 id 和资料缓存不同步

Redis GEO 里建议只放门店 id。门店关闭、迁址、删除时，需要同步更新地理索引；如果短时间内同步失败，详情缓存层也要能识别门店状态，避免把下线门店返回给用户。

4. 距离排序不是唯一排序规则

真实业务里，最近不一定代表最合适。可以先用 GEO 拿到距离，再结合营业中、库存、评分、配送能力做综合排序。Redis GEO 解决的是地理筛选，不替代完整的业务排序。

总结

Redis GEO 适合做附近查询的第一层筛选：门店位置用 GEOADD 写入，用户请求用 GEOSEARCH 按半径检索，结果按距离返回后再补齐门店资料。上线时重点检查经纬度顺序、城市拆 key、半径控制、资料同步和二次排序。把这些边界处理好，附近门店列表就能既快又稳定。