redis排序的数据结构+场景：分数相同，先获得这个分数的人排在前面，用什么方式处理

https://www.nowcoder.com/feed/main/detail/0be6e8fbbec845b392380c150c2f560b

正确答案：可以使用 Redis 的有序集合（Sorted Set，ZSet）数据结构，并结合分数（score）和时间戳（timestamp）构造复合排序键。具体实现方式是将 score 取负或乘以一个大数后加上插入时间戳，确保分数相同时按时间先后排序（先到者优先）。推荐做法是：score 为主排序维度，时间戳为次排序维度，通过 score * LARGE_NUMBER + timestamp 的方式合并为一个数值型 score 存入 ZSet。
解答思路：
1. 明确需求：需要按分数降序排序，分数相同时按获得分数的时间升序排序（即先来者排前面）。
2. Redis 原生的 ZSet 支持按 score 排序，但 score 相同时元素的顺序由字典序决定（即 member 的字符串顺序），无法直接实现“时间优先”。
3. 因此需要将“时间”信息编码进 score 中，使得即使分数相同，也能通过细微差异实现时间先后排序。
4. 设计复合 score：例如 score_scaled = score * 1000000000 + (current_timestamp)，这样高优先级由原始 score 决定，低优先级由时间戳决定。
5. 插入时使用 ZADD 命令，Redis 会自动按合并后的 score 排序。
深度知识讲解：
1. Redis ZSet 的底层实现：
  - 当元素数量少且成员值较短时，使用压缩列表（ziplist）存储；
  - 否则升级为跳表（skiplist）+ 哈希表（dict）的组合结构。
  - 跳表用于维护 score 的有序性，支持 O(log N) 的插入、删除、范围查询；
  - 哈希表用于实现 O(1) 的 member 查找。
  - 因此 ZSet 天然适合做带权重的排名系统。
2. 分数相同如何处理？
  - Redis ZSet 中，如果两个 member 的 score 完全相同，则它们在排序中的相对顺序取决于 member 的字典序（lexicographical order），这不是我们想要的“时间先后”顺序。
  - 所以必须让每个 score 唯一，通过引入时间戳来打破平局。
3. 如何设计复合 score？
  - 方法一：score * LARGE + timestamp
    - 例如：用户得分 85，时间戳为 1712345678，则最终 score = 85 * 1000000000 + 1712345678 = 85000000000 + 1712345678
    - 这样保证高32~64位是原始分数，低部分是时间，排序时先比高位（分数），再比低位（时间）
  - 方法二：使用负时间戳实现“先来排前面”
    - 因为 ZSet 默认 score 升序排列，但我们希望分数高者在前，时间早者在前。
    - 所以可以设 final_score = score * LARGE - timestamp
    - 减去时间戳意味着：时间越早（timestamp 越小），-timestamp 越大，final_score 越大 → 排名越靠前
    - 但注意：这样可能导致负数，需控制范围
  - 方法三：使用双 key + 外部索引（不推荐，复杂度高）
4. 时间戳精度选择：
  - 可使用秒级（10位）或毫秒级（13位）
  - 若用秒级，LARGE 至少取 1e10 避免冲突；若用毫秒，取 1e13
  - 示例：LARGE = 1000000000000LL（1e12）可兼容毫秒级时间戳
5. 实际命令示例：
```
ZADD leaderboard 85001712345678 user1
ZADD leaderboard 85001712345000 user2
ZREVRANGE leaderboard 0 -1 WITHSCORES
```
  结果中 user2 会排在 user1 前面（因为时间更早）
6. 查询排名与反查：
  - ZRANK / ZREVRANK 获取正序/逆序排名
  - ZSCORE 获取某用户的总分（可解析出原始 score 和时间）
  - ZRANGEBYSCORE / ZREVRANGEBYSCORE 支持范围查询
7. 数据解析（从合并 score 提取原始信息）：
  - 原始 score = total_score / LARGE
  - timestamp = total_score % LARGE
8. 边界问题：
  - 数值溢出：Redis score 是 double 类型（64位 IEEE 754），可表示整数最大约 2^53 ≈ 9e15
  - 若 LARGE=1e12，原始 score 最大支持约 9000，足够一般场景
  - 若需更大范围，可降低时间戳精度（如只保留低32位）
扩展应用场景：
1. 游戏排行榜：积分相同则先达成者排名更高
2. 竞赛系统：得分相同者按提交时间排序
3. 积分商城抢兑：积分相同则先排队者优先兑换
4. 社交平台热度榜：点赞数相同则发布时间早者靠前

伪代码示例（插入与查询）：

// 定义常量
LARGE = 1000000000000  // 1e12

// 插入用户分数
function add_user_score(user_id, raw_score):
    timestamp = current_timestamp_milliseconds()  // 如 1712345678901
    final_score = raw_score * LARGE + timestamp
    redis.zadd("leaderboard", final_score, user_id)

// 获取前 N 名
function get_top_n(n):
    result = redis.zrevrange("leaderboard", 0, n-1, withscores=True)
    parsed = []
    for user_id, total_score in result:
        raw_score = total_score // LARGE
        time = total_score % LARGE
        parsed.append({user_id: user_id, score: raw_score, timestamp: time})
    return parsed

// 示例调用
add_user_score("user1", 85)  // time=1712345678000 → score=85001712345678000
add_user_score("user2", 85)  // time=1712345677000 → score=85001712345677000
get_top_n(10)  // user2 排在 user1 前面

注意事项：
- 所有客户端必须使用统一的 LARGE 值和时间戳精度
- 建议使用毫秒时间戳避免同一秒内多次操作冲突
- 可考虑用 Lua 脚本保证原子性操作
- 若需支持分数更新，先 ZREM 再 ZADD（或直接覆盖）

综上，Redis ZSet 结合复合 score 是解决“分数优先、时间次之”排序问题的最佳实践。