Redis Sorted Set 怎样按 score 做稳定分页

Redis Sorted Set 按 score 分页时，建议把 last_score 和 last_member 一起放进游标。score 负责主排序，member 负责同分时的确定性排序；只保存 score，会在同分数据较多时重复读取或漏掉记录。

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

稳定分页的核心不是把 offset 换成一个数字，而是把上一页最后一条记录的完整排序位置保存下来。Redis 对相同 score 的 member 按字典序排列，因此游标至少要包含 score 和 member。

先固定 score 和 member 的排序规则

Sorted Set 的每个 member 都有一个 score。不同 score 按数值排序；score 相同的 member 再按字典序排列，而且 member 本身不能重复。这个规则就是分页接口的排序契约。

例如，下面四条记录的实际顺序是 task-a、task-b、task-c、task-d。其中前三条 score 相同，不能只用 10 表示第三条的位置。

# 用固定的 member 作为同分记录的确定性次序
redis-cli ZADD feed 10 task-a 10 task-b 10 task-c 11 task-d

# 按 score 读取，同时返回 member 和 score，便于生成下一页游标
redis-cli ZRANGE feed -inf +inf BYSCORE WITHSCORES

第一页和后续页怎样设计参数

第一页可以从负无穷查询到正无穷，再取固定数量。响应里同时返回最后一条记录的 score 和 member，并把它们编码成下一次请求的 cursor。不要把用户传入的 offset 直接作为长期分页状态，因为前面插入新记录后，offset 会整体漂移。

# 第一页：从最小 score 开始读取 3 条
redis-cli ZRANGE feed -inf +inf BYSCORE LIMIT 0 3 WITHSCORES

# 只跳过更小的 score；同分记录仍需在应用层按 last_member 过滤
# 示例游标：last_score=10，last_member=task-b
redis-cli ZRANGE feed (10 +inf BYSCORE LIMIT 0 4 WITHSCORES

这里故意多取一条作为缓冲：应用层丢弃 score 等于 last_score 且 member 不大于 last_member 的记录，再补充后续结果。若同分记录可能远多于页大小，不能把“多取一条”当成绝对保证，应改用下面的分段读取策略。

同分记录要拆成两个查询边界

要严格补满一页，可以把下一页拆成两段：第一段读取 last_score 的全部候选，在应用层保留字典序大于 last_member 的 member；第二段读取严格大于 last_score 的记录。先拼接第一段，再用第二段补足页大小。

def next_page(redis, key, last_score, last_member, page_size):
    # 同分段不能只比较 score，要把上页最后一个 member 排除掉
    same_score = redis.zrange(
        key, last_score, last_score, byscore=True, withscores=True
    )
    same_tail = [
        (member, score) for member, score in same_score
        if member > last_member
    ][:page_size]

    # 剩余位置从更大的 score 继续读取，左边界用括号表示不包含
    remaining = page_size - len(same_tail)
    higher = [] if remaining == 0 else redis.zrange(
        key, f"({last_score}", "+inf", byscore=True,
        start=0, num=remaining, withscores=True
    )
    return same_tail + higher

不同语言客户端对参数名的包装可能不同，关键语义是“同分记录按 member 过滤，后续 score 使用排他的左边界”。返回的新游标仍取结果最后一条的完整 (score, member)。

接口边界和性能取舍

游标建议使用 Base64URL 编码的 JSON，例如 {"score":10,"member":"task-b"}，并由服务端生成和解析，避免调用方自行拼接 Redis 范围表达式。页大小也要设上限，防止一次请求拉取过多同分成员。

如果同一个 score 下长期聚集大量记录，读取整段同分成员会变贵。此时可以在写入侧让 score 携带足够细的序号，尽量保证唯一；但要注意 Redis score 使用浮点数，不能无限追加小数位。另一种选择是额外维护可按业务唯一键排序的索引，换取写入和维护成本。

最后要明确一致性语义：游标只能保证排序边界稳定，不能冻结数据快照。分页期间删除记录会让结果变少，更新 score 可能让记录移动到游标前后；如果业务要求严格不变的结果集，应先生成快照或使用带版本条件的数据集。

常见问题

只用 score 作为 cursor 可以吗？不建议。相同 score 的 member 仍需要确定的次序，否则下一页无法知道同分组已经读到哪里。

LIMIT offset count 能替代游标吗？它适合一次性结果切片，不适合会插入新数据的长期分页。稳定分页应保存排序键，而不是保存不断变化的 offset。

为什么不直接使用 BYLEX？BYLEX 适合所有成员使用同一个 score、只按字典序建立范围的场景；本题按 score 主排序时，仍应围绕 score 范围设计游标。