zset靠跳表+哈希表实现o(log n)操作及原子性，配合分片、缓存、避免全量扫描和大key操作，才能支撑千万级并发排行榜。
为什么ZSet在千万级并发下仍能撑住排行榜
ZSet底层是跳表（skiplist）+哈希表双结构，ZADD、ZRANGE、ZRANK平均时间复杂度都是 O(log N)，且所有操作原子性天然支持高并发。但真正扛住千万级的关键不是“单命令快”，而是避免阻塞、减少网络往返和规避大 key 扫描——比如用 ZREVRANGEBYSCORE 替代全量 ZRANGE，用 WITHSCORES 一次取回名次+分数，别分两步查。
千万并发下必须禁用的ZSet操作
以下操作在用户量 >500 万、更新频次 >1k QPS 的排行榜场景中极易打满 CPU 或触发 Redis 阻塞：
-
ZRANGE key 0 -1 WITHSCORES：全量拉取，数据量一过百万就卡顿； -
ZCARD key+ZRANGE key start end分两步算分页：并发高时ZCARD结果可能已过期，且两次 RTT 放大延迟； -
ZREMRANGEBYRANK key 0 -1清空整个排行榜：阻塞主线程，Redis 6.0 前不可中断； - 用
ZINCRBY更新分数但不设MAXLEN：ZSet 无限膨胀，内存泄漏+遍历变慢。
真实业务中怎么设计分段+缓存的ZSet排行榜
纯靠 Redis ZSet 抗千万并发不现实，得配合客户端分片与本地缓存。典型做法是：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 按业务维度分片：比如游戏排行榜按「服务器 ID」或「赛季 ID」切分，每个
leaderboard:season:2024q3独立 ZSet，避免单 key 热点； - 写入走 pipeline：批量
ZADD+ZREMRANGEBYRANK（保前 10 万）合并为一个请求，降低网络开销； - 读取加二级缓存：用
ZREVRANGEBYSCORE key +inf -inf LIMIT 0 100拉取 Top 100，结果存到本地 LRU cache（如 Caffeine），TTL 设 5–10 秒，命中率通常 >95%； - 名次查询用
ZREVRANK而非遍历：用户查自己排名时，直接ZREVRANK leaderboard:user_id，别从头扫。
容易被忽略的内存与精度陷阱
ZSet 的 score 是 double 类型，精度只有 17 位有效数字。当分数来自毫秒时间戳（如 1717023456789）再叠加小数增量（如 +0.001），多次 ZINCRBY 后会发生浮点误差，导致相同分数排序错乱。解决方案：
- score 强制转为整数：用毫秒时间戳 × 1000 当作 score，或用
unix_timestamp * 1000000 + rank_offset构造唯一整型 score； - 内存控制必须做：用
ZREMRANGEBYRANK key 0 -100000定期裁剪，或在ZADD时加CH选项只更新已存在成员，避免无意义插入； - 别把用户完整信息塞进 member 字段：member 只存
user_id，详情查 DB 或缓存，否则 ZSet 内存暴涨且无法序列化复用。
真正的瓶颈往往不在 ZSet 本身，而在没控制好 member 长度、score 精度和跨服务的一致性更新节奏。上线前务必用 redis-benchmark -n 1000000 -c 1000 模拟压测，重点看 used_memory_peak_human 和 instantaneous_ops_per_sec 是否突降。
