Redis GEOSEARCHSTORE 如何缓存地理围栏结果：半径筛选、COUNT 限制与过期复查

配送服务做“附近门店”时，直接对地理索引反复查询并不难，难的是把结果短暂缓存下来后仍能知道它是否过期、是否被旧数据污染。Redis 的 GEOSEARCHSTORE 正好负责“筛选并落到新键”，再配合 EXPIRE，可以把一次围栏查询变成可复查的结果链。

把原始门店坐标放在 GEO 集合里，用 GEOSEARCHSTORE 生成独立结果键，随后立刻设置 TTL；验收时同时检查返回数量、结果内容和剩余时间。

先把原始地理索引和缓存结果分开

假设门店坐标都放在 store:geo，业务要查询“以经度 116.397、纬度 39.908 为中心，半径 3 千米内的门店”。结果不要直接复用这个源键，而是写入 nearby:cache:mall-17。这样原始坐标持续服务于下一次查询，缓存键只承担短期读取。

GEOADD store:geo 116.397 39.908 mall-17
GEOADD store:geo 116.410 39.915 mall-23
GEOADD store:geo 116.360 39.900 mall-41
GEOSEARCHSTORE nearby:cache:mall-17 store:geo FROMLONLAT 116.397 39.908 BYRADIUS 3 KM ASC COUNT 20

命令返回写入 destination 的成员数量。这个数字是第一道检查：返回 0 可能表示围栏内没有成员，也可能是中心点、单位或源键写错，不能只看接口是否返回了 200。

用 GEOSEARCHSTORE 控制半径、数量与距离字段

BYRADIUS 3 KM 是圆形筛选；如果业务给的是矩形配送范围，可以换成 BYBOX width height unit。COUNT 20 只限制结果数量，不等于“距离一定小于某个值”，距离边界仍由圆形或矩形条件决定。

需要按距离展示时加上 STOREDIST。destination 会保存成员及其距离，后续可以用有序集合读取分值；不需要距离时不要无条件加它，先让结果键保持最简单的成员集合。

GEOSEARCHSTORE nearby:cache:mall-17 store:geo \
  FROMLONLAT 116.397 39.908 \
  BYRADIUS 3 KM ASC COUNT 20 STOREDIST
ZRANGE nearby:cache:mall-17 0 -1 WITHSCORES

写入后立即设置 TTL，避免旧围栏长期存活

GEOSEARCHSTORE 会写 destination。只要 destination 已存在，下一次查询就可能覆盖它；而覆盖类命令不会替你建立一个新的过期策略，所以缓存链路应该紧接着设置过期时间。

EXPIRE nearby:cache:mall-17 60
TTL nearby:cache:mall-17
ZRANGE nearby:cache:mall-17 0 -1 WITHSCORES

正常情况下，EXPIRE 返回 1，TTL 返回接近 60 的正数。TTL 返回 -1 说明键存在但没有过期时间，返回 -2 说明键已经不存在；这两种状态都不应被当作“缓存命中”。

生产发布前的权限、覆盖和回滚检查

这个方案的风险不在命令本身，而在结果键管理。首先，destination 命名应包含业务范围或查询版本，避免“商场 17 的 3 千米结果”被另一种参数覆盖。其次，旧结果键如果被覆盖后没有重新执行 EXPIRE，就会脱离缓存生命周期。

上线前可以用下面的检查表逐项确认：

• 源键 store:geo 的坐标由 GEOADD 写入，中心点经纬度顺序未颠倒。
• 半径查询写明了 KM 等单位，COUNT 只承担数量上限。
• GEOSEARCHSTORE 返回数量与 ZRANGE 实际读取数量互相吻合。
• 结果键写入后立即执行 EXPIRE，并在同一条链路里记录 TTL。
• 缓存未命中时回源重建，不能把 TTL=-2 当作空结果永久缓存。

如果命令执行过程中发现中心点或范围参数错误，先删除错误 destination，再修正参数重新生成。不要在错误结果上继续延长 TTL；否则问题会被缓存时间掩盖。

相关问题

GEOSEARCHSTORE 会删除原始地理索引吗？

不会。它读取 source 并把筛选结果写入 destination，原始 store:geo 仍然保留。

COUNT 20 能保证返回最近的 20 个门店吗？

只有在同时指定排序并确认命令语义符合业务要求时，才应把它当作有序候选集；仅写 COUNT 不足以表达“最近”。

为什么 TTL 返回 -1？

这表示结果键存在但没有关联过期时间。检查是否漏掉了 EXPIRE，以及是否在覆盖结果键后重新设置了 TTL。

收尾：把一次地理查询变成可验收的缓存链

可靠的地理围栏缓存至少要能回答三件事：从哪个 source 查、写入哪个 destination、结果什么时候失效。把 GEOSEARCHSTORE 的返回数量、结果读取和 TTL 放在同一条验收链里，半径、数量和过期边界才不会停留在配置猜测上。