Redis GEO原生查询在10万点以上CPU易吃紧，因GEOSEARCH对每个member执行Haversine计算，时间复杂度O(N)；优化需区分场景：位移过滤适用于固定半径、低频更新的矩形裁剪，分片策略则解决写入瓶颈与冷热分离，二者不可混用。
Redis GEO 原生查询在 10 万点以上就容易 CPU 吃紧，单纯靠 GEOSEARCH 拉数据 + 应用层过滤不是长久之计；真正有效的优化是“位移过滤”配合“分片策略”，但这两者不能混用——位移过滤只适用于固定半径、低频更新的场景，而分片主要解决写入瓶颈和冷热分离。
为什么 GEOSEARCH BYRADIUS 在大数据量下变慢
Redis 对每个 member 都要执行一次 Haversine 球面距离计算，时间复杂度是 O(N)，不是 O(log N)。虽然底层用了 Geohash 编码，但 GEOSEARCH 并不利用前缀做索引跳过，而是全量 decode + 计算。实测：50 万点查 1km 范围，平均耗时从 2ms 涨到 45ms，CPU 使用率飙升至 80%+。
常见误判：GEORADIUS 或 GEOSEARCH 返回结果少 ≠ 扫描少 —— 它仍遍历整个有序集合的 score 区间（Geohash 范围比实际地理范围大得多）。
- Geohash 5 位精度（约 4.9km）下，一个 500m 半径圆可能落在 9 个不同 Geohash 格网内，但 Redis 不会自动拆解去查这 9 个前缀
- 纬度接近 ±90° 或经度跨 180°（如阿拉斯加附近）时，Geohash 字符串字典序完全断裂，
ZRANGEBYLEX会漏点 -
WITHDIST和ASC会触发完整排序，即使你只LIMIT 20，Redis 仍需算完所有匹配点的距离再排序
位移过滤（Offset Filtering）适用场景与限制
位移过滤本质是「预计算 + 条件裁剪」：把用户位置按固定网格（如 0.01° 经纬度步长）映射到整数坐标，再用 ZRANGEBYSCORE 查 score 落在某个矩形区间的 member。它绕过了球面计算，但只适合误差可接受、且查询半径固定的业务。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须统一使用 WGS84 坐标系，否则 0.01° 偏差在赤道≈1.1km，在极地≈0km，直接失效
- 经度需做 wrap-around 处理：比如目标经度是 -179.5°，那 -179.5±0.1 的区间要拆成 [-179.5,-179] 和 [179,179.6] 两个 range
- 不能替代距离排序：返回的是矩形框内所有点，需应用层二次按真实球面距离排序并截断
- 适合场景：后台批量导出“某行政区划内商户”，或风控系统查“注册地与登录地偏差 > 5°”的账号
分片策略（Sharding）怎么做才不翻车
分片不是简单按 user_id 取模，而是要让地理邻近的点尽量落在同一分片，否则一次查询要 fan-out 到全部 16 个实例，网络开销反超计算开销。
- 推荐用 Geohash 前 4～5 位作为分片键：例如
geo:shard:wx4g0存所有 Geohash 以wx4g0开头的位置，这样北京五环内点基本落在 2～3 个分片里 - 写入时必须同时写主 GEO key（用于兼容旧逻辑）和分片 key，否则数据不一致；建议用 pipeline 封装这两个操作
- 不要用
user_id % N分片：上海用户和乌鲁木齐用户 hash 到同一分片，但地理上毫无关联，查“上海周边”要扫全量分片 - 分片数建议 8～16，太少起不到分散压力作用，太多导致 fan-out 成本高；可通过
INFO commandstats观察cmdstat_geosearch的 avg_latency 判断是否需要扩容
真正该优先做的三件事
别急着上分片或位移过滤。先检查这三项，80% 的性能问题能当场解决：
- 确认客户端用的是
lettuce6.x+，且启用了pool连接复用；jedis在高并发 GEO 查询下容易连接打满 - 所有
GEOADD加上NX参数，避免重复写入触发不必要的 score 更新（Geohash 重算 + ZSET 重平衡） - 用
EXPIRE给 GEO key 设置 TTL，比如user:geo设为 72h，避免僵尸位置长期拖慢查询
Geohash 分片和位移过滤都是“有损加速”手段，它们把问题从“Redis 算得慢”转移到“应用层要多查、多滤、多排”。只有当原生 GEOSEARCH 真的撑不住（QPS > 300 且平均延迟 > 20ms），才值得引入这些复杂度。
