Redis ZRANGE 返回相同分数成员时怎么保证顺序

Redis 的 sorted set 遇到相同 score 时，ZRANGE 不会记住成员的写入先后，也不会随机挑一个顺序。它先按 score 排列；score 相同，再按 member 的字典序比较。要让排行榜或分页结果可复现，就把真正的二级排序信息编码进 member，或者维护一套专门的二级索引。

先看清 Redis 的同分排序规则

下面这个例子把三个成员写入同一个 key，其中 u:1001 和 u:1002 的分数都是 100：

# 同分成员故意分两次写入，观察顺序是否受写入先后影响
redis-cli ZADD leaderboard 100 u:1002 100 u:1001 99 u:1003

# 正序：先比较 score，再比较同分 member
redis-cli ZRANGE leaderboard 0 -1 WITHSCORES

# 倒序：分数从高到低，同分成员按反向字典序理解
redis-cli ZRANGE leaderboard 0 -1 REV WITHSCORES

正序结果中，分数 99 的成员先出现；两个 100 分成员之间，u:1001 在 u:1002 前面。Redis 官方把这个比较描述为字典序；更准确地说，是逐字节比较字符串。因此大小写、数字补位、非 ASCII 文本都可能影响结果，不能把它当作自然语言排序。

需要稳定二级排序时，如何设计 member

如果业务要求“分数相同按创建时间早的在前”，不要把时间单独存在 Hash 里再指望 ZRANGE 组合排序。常见做法是让 member 自带可比较的二级键，例如把毫秒时间戳格式化为固定宽度，再拼上唯一 ID：

# score 仍表示业务分数，member 的前缀承担同分时的二级排序
redis-cli ZADD feed:rank 100 00001728800000123|post-8f2a
redis-cli ZADD feed:rank 100 00001728800000456|post-91bc

# 同分时按固定宽度时间前缀比较，避免 9 和 10 产生字符串错序
redis-cli ZRANGE feed:rank 0 -1 WITHSCORES

固定宽度很关键：字符串比较不会把 9 理解成数字 9，也不会自动忽略分隔符。成员的唯一 ID 还要保证不重复，因为 sorted set 的 member 本身必须唯一。若同一条内容的 score 会更新，更新 score 不会改变 member；若二级排序字段也变了，就应原子地删除旧 member、写入新 member，并同步业务数据。

分页和范围查询要把边界写清楚

只取前 20 条时，ZRANGE key 0 19 按 rank 查询最直观；按分数筛选则使用 BYSCORE，并配合 LIMIT offset count。如果客户端需要分数，保留 WITHSCORES，不要在应用层重新排序后再拼页。

高并发翻页时，offset 分页会受新增和改分影响。更稳妥的游标应保存上一页最后一个 member 及其 score，再用明确的分数边界和二级键判断下一页；如果业务排序规则很复杂，额外维护一个专门的 sorted set 往往比在应用层拉大集合再排序更清楚。

常见问题

同分成员能不能按插入时间返回？

不能直接依赖 ZRANGE。插入时间不是 sorted set 的隐含字段，必须编码到 member、score，或维护独立索引。

成员是中文时，字典序按什么规则？

按 Redis 存储的字符串字节比较，不等同于中文拼音或数据库的排序规则。需要自然语言顺序时，先生成明确的排序键。

只改 score 会不会破坏同分顺序？

改分会让成员重新落到新的 score 分组；回到同一分数后，仍按 member 比较。二级字段变化则必须同步替换 member。