Redis GEOSEARCHSTORE 怎么核验距离过滤：COUNT、排序与结果集合边界

线上“附近门店”接口偶尔会把上一轮查询的门店带出来，排查后发现问题不在 GEOSEARCH，而在把结果写入固定集合时没有处理旧成员。Redis 的 GEOSEARCHSTORE 适合把一次距离查询固化成新集合，但要同时看清半径单位、COUNT 截断、排序方向和目标集合的生命周期。

把源 GEO 集合作为空间索引，把目标集合当作一次查询快照；每次写入前先清理或换唯一 key，再用 WITHDIST 回读验证结果，才能确认筛选真的生效。

GEOSEARCHSTORE 解决的不是“查附近”本身

假设门店坐标都在 store:geo，接口需要把某个用户位置 5 千米内的候选门店暂存到 store:nearby:ready，后续还要交给库存服务继续过滤。直接用 GEOSEARCH 可以返回列表，但结果只存在响应里；使用 GEOSEARCHSTORE 后，Redis 会把结果成员写进目标有序集合，便于继续读取或交给下一步流程。

这里有个容易忽略的取舍：目标 key 是查询结果容器，不是永久索引。相同目标 key 再写一遍时，如果本轮结果比上一轮少，旧成员可能继续留在集合里，接口于是看起来像“距离过滤失效”。

先准备一组能看出边界的坐标

不要拿全部门店都挤在同一条街上测试。下面四个成员故意安排成近、中、远三档，其中 store:d 在半径外，方便检查数量和范围：

redis-cli GEOADD store:geo 116.3974 39.9093 store:a \
  116.4050 39.9140 store:b \
  116.4200 39.9100 store:c \
  116.4700 39.9300 store:d

redis-cli GEOPOS store:geo store:a store:b store:c store:d

测试时先用 GEOPOS 确认写入顺序和坐标没有颠倒。经度、纬度写反时，命令可能仍然成功，但距离结果会完全偏离预期。

用 BYRADIUS、COUNT 和排序锁定查询语义

下面这条命令以天安门附近的坐标为中心，搜索 5 千米内的成员，按距离从近到远取前三条，并把结果写到新的集合：

redis-cli DEL store:nearby:ready
redis-cli GEOSEARCHSTORE store:nearby:ready store:geo \
  FROMLONLAT 116.3974 39.9093 \
  BYRADIUS 5 km \
  ASC COUNT 3

redis-cli ZRANGE store:nearby:ready 0 -1 WITHSCORES

目标集合仍然是有序集合，分值是 Redis 计算出的距离分值。若业务要把距离返回给调用方，直接在查询阶段加 STOREDIST，或者对源集合使用 WITHDIST 做对照读取，别把有序集合分值当成未经确认的业务字段。

COUNT 截断和旧成员要分别验收

COUNT 3 ASC 的验收至少看三个量：返回成员数不超过 3、每个成员都在 5 km 内、结果顺序没有逆转。可以在命令行把集合读出来，再用一个更宽的只读查询做交叉检查：

redis-cli ZCARD store:nearby:ready
redis-cli ZRANGE store:nearby:ready 0 -1 WITHSCORES
redis-cli GEOSEARCH store:geo FROMLONLAT 116.3974 39.9093 \
  BYRADIUS 5 km ASC WITHDIST

第二个验收点是目标 key 的残留。先写入一个明显不可能命中的旧成员，再执行一轮窄半径查询。如果它仍出现在目标集合，说明“覆盖结果”没有等价于“清空集合”。生产代码可以在写入前 DEL，也可以按请求生成带过期时间的批次 key；不要让多个请求共同覆盖一个固定 key。

兼容处理：先确认 Redis 版本和结果保存策略

GEOSEARCHSTORE 属于较新的 GEO 查询命令。部署前在目标环境执行 INFO server 检查版本，并在同一连接参数下做一次小数据验证。若服务仍处于旧版本，不能只把命令替换成相似拼写；应改为读取 GEOSEARCH 结果后由应用写入临时集合，并补上清理与过期策略。

当结果集合只服务一个请求时，推荐使用请求 ID 作为 key，并设置合理 TTL；当结果需要跨请求复用，则应把查询参数、生成时间和数据版本一起记录。这样距离范围变化时，缓存不会把旧快照误当成新结果。

常见问题

GEOSEARCHSTORE 会自动删除目标集合中的旧成员吗？

不要依赖自动删除语义。固定目标 key 复用前主动删除，或者使用带批次标识的 key 并设置过期时间。

为什么 COUNT 3 返回的结果看起来不是最近的三个？

检查排序参数是否写成 ASC COUNT 3，并确认读取目标集合时使用了正确的范围和分值。还要排除坐标顺序写反。

能不能直接把目标集合当作附近门店缓存？

可以，但必须定义失效策略、查询参数和数据版本。没有 TTL 或批次隔离的固定 key，很容易把上一次请求的成员带入本次结果。

总结

Redis GEOSEARCHSTORE 的关键不只是“能否搜到附近成员”，而是把空间查询转成可复核的结果集合。用坐标样本验证半径，用 COUNT 和 ASC 验证截断与顺序，再单独检查旧成员残留，最后为目标 key 设计清理、TTL 或批次隔离策略，附近搜索才算真正验收完成。