Redis ZRANGESTORE 怎么把筛选后的有序集合范围保存下来

如果一个 Sorted Set 的筛选结果还要被后续请求重复读取，先用 ZRANGE 读到客户端、再执行 ZADD 写回目标 key，至少要拆成读取和写入两次命令。ZRANGESTORE 可以在 Redis 内部完成同一件事：按照排名、分数或字典序取出范围，并直接保存为新的 Sorted Set。

官方地址：https://redis.io/docs/latest/commands/zrangestore/

ZRANGESTORE dst src min max 的核心是“从 src 筛选，再覆盖保存到 dst”。默认按零基 rank 解释边界；加上 BYSCORE 或 BYLEX 后，边界分别改成分数或字典序。

先比较两条结果保存路径

假设 rank:all 里有 10 万个成员，现在要把其中一段保存成 rank:window。客户端搬运方案至少包含一个读阶段和一个写阶段：先把成员及分数传到应用，再把这些数据写回 Redis。数据量变大时，应用层还要承担序列化、网络传输和批量写入。

ZRANGESTORE 将这两个阶段压缩成一个命令路径。这里的“指标”先用命令数量来衡量：客户端回写至少是 1 次范围读取加 1 次目标写入，Redis 侧保存则是 1 次范围保存命令；它不是跨环境压测结论，但足以帮助判断是否有必要把中间结果留在服务端。

# 客户端回写路径：先取成员和分数，再由应用写入目标 key
redis-cli ZRANGE rank:all 2 4 WITHSCORES
redis-cli ZADD rank:window 80 alice 72 bob 68 carol

# Redis 直接保存范围：一次命令完成筛选和目标 key 写入
redis-cli ZRANGESTORE rank:window rank:all 2 4

上面的第二条路径并不代表所有业务都必须改用 ZRANGESTORE。如果应用需要对成员做额外加工，客户端回写仍有价值；如果只是把一个范围作为后续查询的中间 Sorted Set，直接在 Redis 内部保存通常更容易控制传输量和代码复杂度。

按排名保存一段范围

默认情况下，min 和 max 是从 0 开始的 rank，并且两端都包含。先准备一个带有序分数的源集合：

# 准备源 Sorted Set；score 决定默认 ZRANGE 的排序位置
redis-cli ZADD rank:all 55 alice 66 bob 72 carol 81 dave 95 erin

# 保存 rank 1 到 3，目标 key 会接收 bob、carol、dave
redis-cli ZRANGESTORE rank:window rank:all 1 3

# 读取目标 Sorted Set，WITHSCORES 同时显示成员和分数
redis-cli ZRANGE rank:window 0 -1 WITHSCORES

此时 rank 1..3 表示第二到第四个成员，而不是 score 在 1 到 3 之间的成员。负数 rank 仍然可以从末尾计数，例如 -3 -1 表示最后三个成员。最容易出错的地方，是把 rank 边界误当成 score 边界。

用 BYSCORE 和 BYLEX 改变边界含义

当需求不是“第几个成员”，而是“分数落在某个区间”或“成员名按字典序落在某个范围”，需要显式加模式关键字。命令主体仍然是 dst src min max，只是 min 和 max 的解释方式发生变化。

# 只保存 score 在 70 到 90 之间的成员；括号表示排除边界
redis-cli ZRANGESTORE rank:score-window rank:all 70 90 BYSCORE
redis-cli ZRANGESTORE rank:score-open rank:all '(70' '(90' BYSCORE

# 先按相同 score 的 member 做字典序范围筛选；BYLEX 要求相关成员分数相同
redis-cli ZADD rank:lex 0 alice 0 bob 0 carol 0 dave
redis-cli ZRANGESTORE rank:lex-window rank:lex '[bob' '[dave' BYLEX

BYSCORE 的边界可以使用开区间写法，适合保存“高于某分数且不超过另一分数”的结果。BYLEX 不是普通字符串过滤器，它针对相同 score 的成员按字典序解释范围；如果成员的 score 不一致，就不应该把它当成通用的名称筛选命令。

REV 和 LIMIT 怎样组合

REV 会把结果方向反过来，用于从高到低取分数或从后往前取字典序范围。LIMIT offset count 跳过匹配结果的前 offset 个，再最多保存 count 个；它需要与 BYSCORE 或 BYLEX 搭配，不能直接用于默认 rank 模式。

# 从高分到低分筛选，跳过最高的 10 个，再保存接下来的 20 个
redis-cli ZRANGESTORE rank:page-2 rank:all 0 100 BYSCORE REV LIMIT 10 20

# 负数 count 表示保存 offset 之后剩余的全部匹配成员
redis-cli ZRANGESTORE rank:rest rank:all 70 +inf BYSCORE LIMIT 5 -1

# 读取目标 key，确认它已经成为可复用的 Sorted Set
redis-cli ZRANGE rank:page-2 0 -1 WITHSCORES

这里的 LIMIT 不是分页缓存的自动过期机制，也不会为目标 key 设置 TTL。目标 key 一旦写入，就要由业务自行决定是否配置过期时间、何时刷新以及如何处理旧结果。

返回值、覆盖写入和生产边界

ZRANGESTORE 返回保存到目标 Sorted Set 的元素数量。这个数字不是源集合总数，也不是被扫描过的成员数量；如果范围没有匹配项，目标结果集会为空，返回值也会反映这一点。

目标 key 会被本次结果覆盖。换句话说，旧目标集合里原本存在、但这次没有被筛选出来的成员不会继续保留。刷新一个派生排行榜时，这种覆盖语义很方便；如果目标 key 里还有不应该丢失的独立数据，就不要直接复用它。

如果命令报错，不要把它和“返回 0 个元素”混为一谈。客户端应先处理命令错误，再读取正常返回值。尤其在 Redis Cluster 中，源 key 和目标 key 的访问关系需要结合部署方式确认，不能只看单机命令示例。

把筛选规则固定成可维护配置

当同一类范围结果会周期性刷新，可以把四项参数放在一起维护：源 key、目标 key、范围模式和边界。这样遇到结果突然变少时，先核对配置，再判断是源数据变化还是参数变化。

在监控或日志里，至少保留目标 key、返回数量和规则版本。这样可以把“这次没有结果”与“命令没执行”区分开，也能看出分页配置是否在某次发布后发生了变化。

常见问题

ZRANGESTORE 的 min 和 max 默认是 score 吗？

不是。默认按零基 rank 解释；只有加上 BYSCORE 时才按分数边界解释，BYLEX 则按字典序边界解释。

为什么 LIMIT 不能直接跟在 rank 范围后面？

官方命令语义要求 LIMIT 与 BYSCORE 或 BYLEX 一起使用。需要 rank 分页时，应先明确业务是否可以改成分数或字典序分页，不能只把参数硬拼到命令末尾。

目标 key 已经存在时会追加结果吗？

不会按追加理解。目标 key 保存的是本次筛选得到的结果集，旧结果会被本次写入替换；需要保留旧数据时，应使用不同目标 key 或先设计独立的合并逻辑。

ZRANGESTORE 和 ZRANGE 有什么区别？

ZRANGE 把结果返回给客户端，ZRANGESTORE 把结果写入目标 Sorted Set。前者适合立即展示或继续在应用层处理，后者适合需要在 Redis 中重复读取的派生范围。

可以把它记成一句话：ZRANGESTORE 负责把“筛选出来的 Sorted Set 范围”变成一个新的 Redis 结果集。先选对 rank、BYSCORE 或 BYLEX，再确认 REV、LIMIT、覆盖写入和集群边界，范围缓存就不会只停留在一条看似正确的命令上。