Redis ZSET 分数相同的稳定排序设计

做排行榜、任务优先级或“同一分数下仍要顺序稳定”的查询时，Redis ZSET 最容易被忽略的一点是：score 相同并不等于结果无序。Redis 会先比较分数；分数相同后，再按 member 的字典序排列。因此，真正要设计的是 member 的可比较形式，而不是依赖成员写入的先后顺序。

如果同分时只要求结果可重复，直接接受 Redis 的字典序即可；如果同分时有明确的创建序号、业务 ID 或时间顺序，就把经过规范化的二级排序键编码进 member，再在读取端拆回真实成员。

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

下面按一次实际工程取舍来拆解：先确认 Redis 的默认规则，再设计 member 格式，最后说明 Go 客户端如何读取以及分页和编码边界。文中的图片是静态结构说明图，不是 Redis 终端截图，也不表示本机运行结果。

同分成员为什么仍然有固定顺序

我第一次遇到这个问题是在一个分数只有几个离散等级的列表里：很多成员的分数都是 100，产品却要求刷新页面后顺序不要来回跳。直觉上很容易把问题归因于 Redis 的写入顺序，但 ZSET 的排序规则并不是“谁先写入谁靠前”。

Redis 文档给出的规则是：元素先按从低到高的 score 排序；score 相同的元素按 member 的字典序排列。这里的字典序是按字符串的二进制字节比较，普通 ASCII 字符看起来像常见的字典排序，但中文或其他 UTF-8 字符不应按自然语言拼音去猜。

ZADD task_rank 100 task:0000000007 100 task:0000000003 100 task:0000000012
# 三个任务分数相同，member 中的定宽序号承担同分比较
ZRANGE task_rank 0 -1 WITHSCORES
# 返回顺序会按 member 的可比较字节排列，而不是按 ZADD 的写入顺序

这个默认行为已经足够解决“同分结果必须可重复”的需求，但它不一定等于业务想要的顺序。比如业务希望同分时按创建时间升序，或者按数值型用户 ID 升序，那么就应该把这个规则显式编码出来。

把业务二级排序写进 member

稳定排序设计的关键是让 member 的前缀能够按字节序表达业务顺序。最常见的做法是使用固定宽度的十进制序号，或者使用按字典序可比较的时间/ID 编码。例如，若序号最大为 9 位，可以把真实成员写成 task:000000003|42，其中前面的数字用于排序，后面的 42 是业务对象 ID。

定宽很重要。把数字 3、12、100 直接拼到字符串里，字典序可能得到 100、12、3，和数值顺序相反。统一补零后，003、012、100 才能保持预期顺序。

package main

import (
    "fmt"
)

func encodeMember(seq int64, objectID string) string {
    // 固定宽度让字符串字典序与序号升序一致；分隔符便于读取端拆分。
    return fmt.Sprintf("task:%010d|%s", seq, objectID)
}

func main() {
    // 业务对象 ID 放在排序前缀之后，展示时可以再拆回原值。
    fmt.Println(encodeMember(12, "42"))
}

在真实项目中我更倾向于用明确的分隔处理函数，而不是依赖复杂格式扫描。无论采用哪种实现，都要把 member 格式当作数据契约：一旦上线，修改前缀宽度、分隔符或字符集，就可能改变同分成员的排序和解析结果。

Go 读取时怎样保留真实成员

写入端把排序字段放进 member 后，读取端要做两件事：保留 Redis 返回的原始 member，拆出展示用的对象 ID，并把 score 单独保留。这样既能解释为什么排在前面，也不会把排序键误当成用户看到的名称。

go-redis 提供了结构化的 ZSET 读取方法。下面的代码使用 ZRangeWithScores 得到成员和分数；它只是客户端读取方式，稳定性仍然来自 Redis 的 score 加 member 排序规则。

package rank

import (
    "context"
    "fmt"
    "strings"

    "github.com/redis/go-redis/v9"
)

type rankedTask struct {
    RawMember string
    ObjectID  string
    Sequence  string
    Score     float64
}

func displayTask(row redis.Z) (rankedTask, error) {
    // 原始 member 是 Redis 的排序依据，解析失败时不能静默丢掉它。
    member := fmt.Sprint(row.Member)
    prefix := strings.TrimPrefix(member, "task:")
    parts := strings.SplitN(prefix, "|", 2)
    if len(parts) != 2 {
        return rankedTask{}, fmt.Errorf("invalid member %q", member)
    }
    return rankedTask{
        RawMember: member,
        Sequence:  parts[0],
        ObjectID:  parts[1],
        Score:     row.Score,
    }, nil
}

func loadTasks(ctx context.Context, client *redis.Client) ([]rankedTask, error) {
    // 0 和 -1 表示整个索引范围；分页时改成明确的闭区间。
    rows, err := client.ZRangeWithScores(ctx, "task_rank", 0, -1).Result()
    if err != nil {
        return nil, fmt.Errorf("read task rank: %w", err)
    }
    tasks := make([]rankedTask, 0, len(rows))
    for _, row := range rows {
        task, err := displayTask(row)
        if err != nil {
            // 坏 member 不应进入展示列表，否则同分顺序难以追查。
            return nil, err
        }
        tasks = append(tasks, task)
    }
    return tasks, nil
}

这里没有再对返回结果做一次排序。原因是二次排序很容易把 Redis 已经给出的确定顺序覆盖掉，甚至让应用层和 Redis 的分页边界不一致。读取端只负责解析；如果业务规则变了，应修改 member 编码方案并重建对应集合，而不是在每次查询时临时补排序。

分页、REV 和编码边界怎么处理

ZRANGE key start stop 的索引范围是闭区间，索引从 0 开始，-1 表示最后一个元素。如果每页 20 条，第一页可以读 0,19，第二页读 20,39。同分成员已经被稳定地排进这个索引序列后，分页结果才有机会保持一致。

ZRANGE task_rank 0 19 WITHSCORES
# 第一页包含索引 0 到 19，共 20 个位置
ZRANGE task_rank 0 19 REV WITHSCORES
# REV 从高分到低分读取；同分时使用反向字典序

如果使用 REV，不仅分数方向反过来，同分成员的字典序也会反向。不要只在代码里把结果数组倒过来，因为那样无法精确表达 Redis 的反向索引范围，也可能和后续的 LIMIT、按分数查询产生不同结果。

还要注意几个格式边界：

• member 中的排序前缀必须有固定长度，不能让数字宽度随数据增长。
• 分隔符不能出现在 object ID 中，或必须使用可靠的转义规则。
• 不要用中文展示名直接承担跨语言排序契约，UTF-8 字节序不等同于拼音序。
• 如果二级字段是时间，先统一时区和精度，再编码；否则相同业务时间可能出现不可预期的细分顺序。
• 如果必须保留精确的小数语义，score 的浮点表示要单独评估，不能把显示字符串当作精确金额。

我会怎样选择这套设计

对我来说，判断标准很简单：如果同分时只要“每次一样”，让 member 采用稳定的业务 ID 或定宽序号就够了；如果同分时需要“按创建时间、优先级或人工规则”，把排序字段编码进 member，并在写入和读取处共用同一份契约。

这套设计的代价是 member 不再只是一个纯展示 ID，修改排序规则时通常要迁移集合。它换来的好处是 Redis 的查询、分页和应用展示使用同一个确定顺序，不需要每次拉取后再做昂贵的全量排序。对于数据量较大、分页边界敏感的列表，这个取舍通常更容易维护。

常见问题

Redis ZSET 同分时会按写入先后排序吗？ 不会。默认先按 score，再按 member 的字典序；写入先后不是稳定排序契约。

同分时能不能直接用时间戳作为 member 前缀？ 可以，但要统一精度、格式和方向。若要按时间升序，建议使用固定宽度、可字典序比较的编码，并把业务 ID 放到后面消除完全相同的时间值。

为什么应用层还要保留原始 member？ 原始 member 是 Redis 排序的依据。只保留拆出的展示 ID，会丢失排查排序漂移所需的上下文。

score 相同但 member 也相同会怎样？ ZSET 的 member 本身唯一；再次写入相同 member 会更新它的 score，而不是生成两个相同成员。