题目：如何实现百万级排行榜功能？
难度：high
评分：⭐⭐⭐⭐☆☆（3/5）
百万级数据的排行榜也不会查看全部百万的数据,在缓存中只会加载 topN 前置查看 topN 可以直接在 redis 中通过 zset 去实现,按照对应分数设定排序,超出预期的内容,如果有查看的,可以基于数据库去对分页内容进行查询,这部分业务逻辑实现的话就去基于数据库做就好了,查看频率会比较低,可以在排行榜处增加查看更多,点击后查看,然后跳转到独立页面进行单独实现,这堆查看并发量就没那么高了
优点：
Top N 缓存 + DB 分页思路抓到- 查看更多跳转独立页面方案对
不足：
❌ 遗漏 Top N 大小如何确定- ❌ 遗漏排行榜实时性（Lua 原子更新/消息队列异步）- ❌ 遗漏分维度排行榜（实时/小时/日/周榜）- ❌ 遗漏排行榜降级方案- ❌ 遗漏排行榜防作弊- ❌ 遗漏并发更新性能优化- ❌ 遗漏 ZREVRANK 获取排名 O(log N)
核心考点：考察大规模排行榜的架构设计能力，理解"缓存 + DB"分层策略。
知识点拆解：
关键性能指标：
面试官您好，百万级排行榜的核心思路是缓存只存 Top N，其余走 DB 分页。
Top N 大小根据业务需求和性能确定，一般 Top 1000 覆盖 99% 展示需求。ZREVRANGE 0 999 在百万级 Zset 上 O(log n + 1000)，毫秒级响应。
架构分层：Redis Zset 存 Top 1000，实时查询；MySQL 存全量数据，分页查询。Top N 外用户点击"查看更多"跳转独立页面，DB 分页查询。
排行榜实时性：Lua 原子更新（ZADD + ZREVRANGE 原子执行，避免并发不一致）、MQ 异步更新（业务事件发 MQ，消费者更新 Zset，削峰解耦）、定时刷新（兜底）。
分维度排行榜：实时榜、小时榜、日榜、周榜用多个独立 Zset，每个维度独立过期时间。
降级方案：缓存宕机降级到只读 DB（限流），DB 宕机只展示 Redis 缓存数据，MQ 积压降级为定时刷新。
防作弊：异常分数检测（突增告警）、频率限制（单用户更新频率）、黑名单机制。
性能指标：Top 1000 查询 O(log n + 1000) 毫秒级，更新分数 O(log n) 毫秒级，获取排名 O(log n) 毫秒级。