不能直接用单个geo key存所有城市数据，因会导致内存膨胀、主线程阻塞（500万点查询耗时200ms+）、无法水平扩展；redis集群不支持跨key geo查询，必须用城市前缀分片（如geo:city:beijing）并由应用层聚合跨城结果。
为什么不能直接用单个 GEO key 存所有城市数据
直接把全国用户或商户全塞进一个 geo:locations key，看似简单，但会立刻暴露三个硬伤：内存膨胀、阻塞主线程、无法水平扩展。Redis 的 GEORADIUS 是单线程执行的，当这个 key 里有 500 万点，一次半径查询可能耗时 200ms+，而高并发下排队请求会堆积，latency spikes 直接触发监控告警。更麻烦的是，你没法把一个 GEO key 拆给多个 Redis 实例——它不是原生分片数据结构，redis-cluster 对 GEO 命令的支持也仅限于 KEYS 路由层面，不解决单 key 瓶颈。
用城市编码前缀做逻辑分片：最稳的落地方式
放弃“自动分片”幻想，采用显式前缀分片（sharding by prefix），是当前生产环境最可控的做法。核心就是：**把城市维度作为 key 的一部分，而非 member 名的一部分**。
-
geo:city:beijing存北京用户，geo:city:shanghai存上海用户，geo:city:guangzhou存广州用户——每个 key 都是独立的 GEO 结构，互不影响 - 城市编码统一用标准拼音小写（如
beijing）或 ISO 3166-2 行政编码（如cn-bj），避免中文、空格、大小写歧义 - 客户端写入前先查城市归属（可用离线 GeoIP 库或前端传参），再拼出完整 key，例如
geo:city:+cityCode - 不要用
geo:locations+city:beijing:user:1001这种嵌套 member，member 必须是轻量 ID（如u1001），否则GEORADIUS返回结果解析成本陡增
如何避免跨城市查询失效
真实业务常要查“周边 10km”，而用户可能刚好在城市交界处（比如苏州园区靠近上海青浦）。纯按城市分片后，GEORADIUS geo:city:suzhou 120.7 31.3 10 km 会漏掉青浦的商户——这是分片带来的必然代价，必须由上层补偿。
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 对高精度场景（如打车、外卖），强制要求客户端上报 GPS 坐标，并在服务端做「双城查询」：
GEORADIUS geo:city:suzhou ...+GEORADIUS geo:city:shanghai ...，然后合并去重 - 用
GEORADIUSBYMEMBER替代部分场景：若已知用户属于suzhou，但想查“他附近上海用户”，可先GEORADIUSBYMEMBER geo:city:suzhou u1001 10 km拿坐标，再手动调用GEORADIUS geo:city:shanghai {lng} {lat} 10 km - 绝不依赖
GEORADIUS的STORE/STOREDIST参数做跨 key 写入——Redis 不支持跨 key 原子操作，会引发数据不一致
分片后运维和冷热分离怎么搞
分片带来 key 数量上升，但换来的是可预测的资源占用和灵活的生命周期管理。
- 给每个城市 key 加 TTL：北京用户活跃度高，设
EXPIRE geo:city:beijing 86400（24h）；三线城市低频，可设 7 天，用EXPIREAT定时清理 - 冷数据归档：用
GEORADIUS批量导出低活跃城市的点，转存到PostGIS或Elasticsearch，只在 Redis 留最近 7 天热数据 - 监控重点从 “单 key size” 切换到 “同前缀 key 数量分布”，例如用
SCAN 0 MATCH geo:city:* COUNT 1000统计各城市 key 数量，防止单个城市突发写入打爆实例 - 别忘了
GEOHASH命令本身不跨 key，如果要做全局 geohash 前缀扫描（比如查所有wx4g0开头的点），必须自己聚合多个 city key 的结果——这恰恰说明：GEO 分片后，就不再适合做“全国模糊地理检索”了
分片不是银弹，它把“单点压力”转化成了“多点协调成本”。真正容易被忽略的，是业务方对「地理边界模糊性」的接受程度——技术可以分片，但用户不会按行政区划移动。
