必须分片，因单key geoadd底层zset会导致查询o(logn+m)延迟、rdb/aof fork超时、无法水平扩展；应按geohash前4-5位分key，查时用邻区算法并发查最多9个key并合并去重排序。
Redis GEO 数据量过大时，GEOADD 单实例写入会遇到内存瓶颈、响应延迟升高、ZSET 范围查询变慢等问题——这不是靠调优参数能解决的，必须从存储结构层面拆分。
为什么不能直接往一个 key 里狂塞几百万个位置
Redis 的 GEOADD 底层用的是 ZSET，score 是 52 位整数（Geohash 编码对齐后），member 是字符串。问题在于：
- 所有点都挤在同一个
ZSET中，GEORADIUS查询需遍历整个跳表范围，时间复杂度接近 O(log N + M)，M 是命中数量，N 是总数据量 - 单 key 过大导致 RDB/AOF 文件膨胀，fork 子进程耗时剧增，甚至触发超时或 OOM
- 无法水平扩展：一个 key 无法跨节点分布，
Redis Cluster对ZSET的哈希槽分配只看 key 名，不看 member
GeoHash 分片的核心逻辑：用前缀做路由键
不是把 Geohash 当作纯编码存着，而是把它变成分片依据。例如取 Geohash 前 4 位（如 "wx4g"）作为子 key 后缀，把原始位置按该前缀分散到不同 key：
GEORADIUS cities:wx4g 116.397 39.916 10 km GEORADIUS cities:wx4f 116.397 39.916 10 km GEORADIUS cities:wxtq 116.397 39.916 10 km
这样做的前提是：
- 插入时先算出完整 Geohash（如
"wx4g0b1j7d"），截取前缀生成 key 名（如"cities:wx4g"），再执行GEOADD cities:wx4g 116.397 39.916 "poi_123" - 查询时不能只查一个前缀——因为目标点半径可能跨多个 Geohash 区域，需调用
geohash_neighbors()获取最多 9 个邻接前缀（中心 + 8 方向），然后并发查对应 key - 前缀长度要权衡：太短（如 2 位）导致 key 数少、单 key 仍臃肿；太长（如 6 位）则 key 数爆炸、客户端聚合成本高；生产常用 4～5 位（对应约 ±2.5km ~ ±0.6km 精度）
容易被忽略的边界坑：邻区查询不等于简单加减字符
Geohash 邻接区域不是字符串字典序相邻，比如 "wx4g" 的北边不是 "wx4h"，而是需要专用算法解码坐标、偏移后再编码。别手写字符串拼接，否则漏查率极高。
- Python 可用
geohash2.neighbors()，Java 推荐spatial4j或geo3k库里的GeoHash.getAdjacent() - Redis 本身不提供跨 key 的
GEORADIUS聚合，客户端必须自己合并多个GEORADIUS结果，并去重（member 名重复时）、排序（按距离） - 如果业务允许误差，可先用前缀定位主 key，再用
GEORADIUSBYMEMBER查局部，避免查全部 9 个邻区——但半径超过前缀对应边长一半时，就不可靠
配合分片的其他必要动作
光分片不够，还得配套处理：
- 冷热分离：高频访问的城市中心区域（如
"wx4g"）单独部署为高配节点，低频郊区前缀可共用普通节点 - 过期控制：不用
EXPIRE整 key 过期（会丢数据），改用ZREMRANGEBYSCORE清理 score 超出时间戳范围的 member（需把时间戳混入 score，例如高位放 Geohash、低位放 Unix 时间） - 写入加速：对批量导入，用
PIPELINE封装同前缀的多条GEOADD，比逐条快 5～10 倍；注意 pipeline 不是事务，失败需重试
真正难的不是算 Geohash，而是邻区覆盖的完整性验证和跨 key 结果的有序归并——很多线上事故都出在查了 8 个邻区却漏掉第 9 个，或者距离排序错乱。上线前务必用真实地理分布数据压测边界案例。
