ZSet 是排行榜首选，因其天然按 score 排序且核心操作平均 O(log N)；支持 member 唯一、score 可重复，适合用户 ID 作 member、行为分作 score；需规避浮点精度、score 溢出及高频写放大问题。
为什么 ZSet 是排行榜的首选数据结构
因为 ZSet 天然支持按分数（score）排序，且插入、更新、查询排名、获取 Top N 等操作平均时间复杂度都是 O(log N)，远优于用 List + 排序或内存中排序。它还支持重复 member 但唯一 score（实际是 member 唯一，score 可重复），这点对用户 ID 作 member、行为得分作 score 的场景非常贴切。
常见误区是把业务权重直接当 score 存——比如「点赞×2 + 评论×5」这种动态公式，如果每次变更都重算并 ZADD，会引发高频写放大；更稳妥的做法是只存原子行为分，用 Lua 脚本或服务端聚合计算实时权重，ZSet 仅承载最终排序依据。
ZADD 和 ZRANGE 的典型用法与陷阱
ZADD 写入时注意：同一 member 多次调用会自动更新 score，无需先 ZREM；但若传入多个 member-score 对，其中某个 member 已存在，其余仍会正常写入，不会报错也不会跳过。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 正确更新单个用户积分：
ZADD leaderboard 850 user:1001 - 批量写入多个用户（含已存在者）：
ZADD leaderboard 720 user:1002 910 user:1003 850 user:1001 - 错误写法（想“只增不替”，但 ZSet 没这个模式）：
ZADD leaderboard NX 850 user:1001——NX参数只对本次新增有效，不影响其他 pair；且一旦user:1001已存在，整条命令仍成功，只是该 member 的 score 不变 - 查 Top 10 且带分数：
ZRANGE leaderboard 0 9 WITHSCORES；漏掉WITHSCORES就只能拿到 member 列表，无法知道具体得分
如何高效获取某用户的实时排名和前后邻项
用 ZRANK 获取升序排名（从 0 开始），ZREVRANK 获取降序排名（排行榜通常用后者）；但要注意：ZSet 中 score 相同时，排名按 member 字典序决定，不是插入顺序——这点在 score 集中（如大量用户同为 100 分）时会导致排名抖动。
- 查用户当前降序名次：
ZREVRANK leaderboard user:1001（返回 0 表示第 1 名） - 查该用户前后各 2 名：
ZREVRANGE leaderboard [rank-2] [rank+2] WITHSCORES，需先用ZREVRANK查出 rank，再拼接范围——不能直接用ZRANGEBYSCORE，因为 score 可能重复 - 避免 N+1 查询：不要先
ZREVRANK再ZREVRANGE，两次网络往返；应改用 Lua 脚本原子执行
例如 Lua 脚本获取 user:1001 的排名及附近 3 人：
local rank = redis.call("ZREVRANK", KEYS[1], ARGV[1])
if not rank then return {} end
local start = math.max(0, rank - 1)
local stop = rank + 1
return redis.call("ZREVRANGE", KEYS[1], start, stop, "WITHSCORES")
score 设计必须避开浮点精度与溢出问题
ZSet 的 score 是双精度浮点数（IEEE 754），看似支持大数，但超过 2^53（约 9e15）后无法精确表示整数，会导致 ZRANGEBYSCORE 区间查询错位或 ZADD 覆盖异常。排行榜场景强烈建议用整型 score，且控制在 ±2^50 内。
- 别用毫秒时间戳当 score（17 位数字易超限），改用秒级或归一化缩放：
score = floor(timestamp / 60) * 1000000 + user_id % 1000000 - 权重合成时避免小数：「活跃度 × 0.7 + 贡献度 × 0.3」应转为整数运算，如
(active * 7 + contribution * 3) / 10，或直接放大 100 倍存整数 - 慎用负 score：虽然合法，但
ZREVRANGE和ZRANGEBYSCORE的边界逻辑容易混淆，非必要不引入
真正难的不是命令怎么写，而是 score 的语义是否稳定、能否覆盖未来 2 年的业务增长量级，以及 score 更新频率是否会让 AOF/RDB 文件膨胀过快——这些得在第一次 ZADD 前就想清楚。
