Redis GEO命令通过Geohash编码实现O2O附近检索，推荐6–8位精度，按城市/品类分key建模，优先使用GEOSEARCH查询并辅以半径放大+应用层距离过滤兜底。
直接用 Redis 的 GEO 命令就能实现 O2O 场景下的极速附近检索，核心不在“写多复杂”，而在“数据怎么存、查询怎么发、边界怎么兜”。它本质是把经纬度转成有序集合里的分数，靠 Geohash 编码的空间局部性做快速范围筛选。
GeoHash 编码决定精度和性能平衡
Redis 内部用 52 位整数表示 Geohash，不是字符串。长度越长，定位越准，但存储略增、编码开销微升；太短则容易漏掉边缘商户。O2O 场景推荐用 6～8 位精度：
- 6 位：约 1.2km × 0.6km 单元格，适合“查本城区所有奶茶店”
- 7–8 位：38m × 19m 级别，可支撑“步行 500 米内可用优惠券门店”这类精细化运营
- 避免盲目用 12 位——厘米级对门店搜索毫无意义，还浪费内存和计算
数据建模：用好 GEOADD 和 key 设计
不要把所有商户塞进一个 key（比如 all_shops）。按业务维度拆分更可控：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 按城市分 key：shops:beijing、shops:shenzhen，降低单 key 数据量，提升 GEORADIUS 响应稳定性
- 按品类分 key：shops:coffee:shanghai、shops:pharmacy:shanghai，支持“附近咖啡馆”“附近药店”独立索引
- member 推荐用业务 ID（如 shop:1024），而非名称，避免中文或空格引发解析问题
- 一条命令可批量添加：GEOADD shops:coffee:beijing 116.40 39.90 "shop:1024" 116.42 39.91 "shop:1025"
查询优化：优先用 GEOSEARCH（Redis 6.2+），替代老式 GEORADIUS
GEORADIUS 在大范围半径下可能扫到大量无效点再过滤；GEOSEARCH 更智能，能结合 COUNT、WITHDIST、SORT BY DIST 自动裁剪和排序：
- 查 1km 内最多 20 家咖啡店，按距离由近到远：
GEOSEARCH shops:coffee:beijing FROMMEMBER "shop:1024" BYRADIUS 1 km COUNT 20 ASC WITHDIST - 支持坐标直查（不用先存中心点）：
GEOSEARCH shops:coffee:beijing FROMLONLAT 116.40 39.90 BYRADIUS 500 m - 加 WITHCOORD 可同时返回经纬度，前端渲染地图标记不需额外查库
兜底与容错：应对 Geohash 边界问题
Geohash 的“格子切割”会导致紧邻但跨格的两个点一次查不到。O2O 不能漏单，建议双保险：
- 主查询用稍大半径（如用户选“500 米”，实际查 600 米），再在应用层按真实球面距离（haversine 公式）二次过滤
- 对高价值场景（如急救药房、充电桩），可额外维护一份“区域哈希前缀索引”，比如预计算每个门店所属的 5 位 Geohash 前缀，查询时取中心点 5 位前缀 + 相邻 8 个前缀，合并去重后查详细坐标
- 缓存高频中心点（如商圈中心、地铁口）的 GEOSEARCH 结果，设置较短 TTL（如 30 秒），减轻 Redis 压力
