Redis Cluster中GEORADIUS查不到数据是因为该命令仅查询单个key所在节点，若地理数据分散在多个key或未用{}哈希标签强制同slot，则无法跨节点检索；必须用geo:{tag}:key统一slot或应用层聚合多节点结果。
GEORADIUS在集群里查不到数据，根本不是命令写错了
Redis Cluster 的 GEORADIUS 命令只作用于单个 key，而该 key 必然只落在一个节点上。如果你的地理数据分散在多个 key（比如 geo:beijing、geo:shanghai），或者没加哈希标签导致同一业务维度的 key 被散列到不同 slot，那 GEORADIUS 就只能返回局部结果——这不是漏查，是压根没去其他节点查。
常见错误现象包括：
- 查“上海周边 5km 用户”，结果只返回上海节点上的部分用户，杭州、苏州的用户完全不出现
- 用
geoadd geo:all 121.47 31.23 "u1"写入后，georadius geo:all返回空，因为geo:all被路由到 A 节点，但写入时可能被重定向到 B 节点（没加{}）
必须用 {} 强制所有 GEO key 落在同一 slot
Redis 只对第一个 {} 内的字符串做 CRC16 计算，其余部分忽略。想让整个地理集合可被单次 GEORADIUS 扫描，唯一办法是确保所有相关数据都在同一节点——靠 {} 实现。
正确写法示例：
geoadd geo:{lbs}:users 121.47 31.23 "u1"
geoadd geo:{lbs}:users 120.15 30.28 "u2"
georadius geo:{lbs}:users 121.47 31.23 5 km
关键规则：
-
{}必须成对出现，且只取第一个有效对；geo:{lbs}:v2:users和geo:{lbs}:meta效果一样 -
{}内不能为空，geo:{}:users会被当作整个 key 计算 slot - 业务上要选稳定、有区分度的字段做 tag，比如租户 ID、区域 code，避免全用
{common}导致数据倾斜
不用 {} 的替代方案：应用层聚合多节点结果
如果业务上无法统一 key 前缀（比如已上线系统、多租户隔离强、或 GEO 数据天然按城市分片），就不能依赖单次 GEORADIUS。此时必须由客户端主动发起多次查询并合并结果。
实操要点：
- 先根据目标经纬度和半径，预估可能覆盖的区域范围（比如用 GeoHash 前缀或行政区划边界）
- 构造对应 key 列表（如
geo:shanghai、geo:suzhou、geo:hangzhou） - 对每个 key 单独调用
GEORADIUS，注意设置WITHDIST、WITHCOORD等参数保持字段一致 - 在应用层去重（靠 member 名唯一）、排序（按距离）、截断（取 topN）
性能影响明显：一次请求变成 N 次 RTT，且无法利用 Redis 内部跳表的 O(log N) 范围扫描优势。
GEORADIUSBYMEMBER 同样受 slot 限制，别指望它绕过
有人误以为 GEORADIUSBYMEMBER 是“基于已有成员查周边”，能自动跨 key 关联——其实它和 GEORADIUS 底层都走同一个逻辑：只查指定 key 所在节点上的 zset 数据。只要 key 不在同 slot，就不存在“关联”一说。
错误写法：
geoadd geo:shanghai 121.47 31.23 "u1" geoadd geo:hangzhou 120.15 30.28 "u2" georadiusbymember geo:shanghai "u1" 5 km // 只查 shanghai 节点，u2 永远不会出现
真正要注意的复杂点是：GEO 命令底层复用 zset，而 zset 的跳表结构决定了它无法像关系数据库那样做 join 或跨 key 排序。所有“跨区域”语义，必须由业务自己定义和实现——要么靠 {} 把数据收拢，要么靠应用层兜底。没有中间路线。
