必须用 Redis ZSET 实现排行榜，因 MySQL ORDER BY 在高并发或大数据量时性能急剧下降；ZSET 支持 O(log N) 排序、范围查询与排名计算，而 ThinkPHP 缓存封装不支持结构化操作，需通过 Cache::handler() 获取原生 Redis 实例调用 zAdd、zRevRange 等方法，并确保业务更新时原子性同步、设置过期时间、及时清理无效数据。
排行榜数据为什么必须用 Redis 有序集合（ZSET）
直接用数据库 ORDER BY score DESC LIMIT 10 查排行榜，在并发稍高或数据量过万时，会迅速拖慢响应、压垮 MySQL。Redis 的 ZSET 天然支持按分值排序、范围查询、排名计算，且所有操作都是 O(log N) 时间复杂度——这才是实时排行榜的底层支撑。
ThinkPHP 自带的缓存驱动（如 redis）默认不暴露 ZSET 原生命令，必须绕过 Cache 类，直连 Redis 实例才能使用 ZADD、ZREVRANGE、ZREVRANK 等核心方法。
- 别试图用
Cache::set('rank:202406', $data)存整个数组——无法排序、无法增量更新、无法查排名 - ThinkPHP 的
cache()函数只封装了字符串/数组的读写，不支持结构化数据操作 - 必须通过
think\facade\Cache::handler()或手动 new Redis 实例获取原生连接
如何在 ThinkPHP 中安全获取 Redis 原生连接并操作 ZSET
推荐使用 think\facade\Cache 的 handler() 方法，它返回当前配置的 Redis 实例（前提是缓存驱动已设为 redis），避免重复配置连接参数：
// 获取原生 Redis 实例（ThinkPHP 6.0+）
$redis = \think\facade\Cache::handler();
<p>// 添加用户得分（自动去重，分数更高则覆盖）
$redis->zAdd('rank:week', $score, $user_id);</p><p>// 取前 10 名（含 score 和 member）
$top10 = $redis->zRevRange('rank:week', 0, 9, ['withscores' => true]);</p><p>// 查某用户当前排名（从 0 开始，+1 即真实名次）
$rank = $redis->zRevRank('rank:week', $user_id);
if ($rank !== false) {
$rank += 1;
}- 注意
zRevRank返回的是 0-based 索引，业务展示需 +1 - 若用
zScore查不到分数，返回false，不是null或 0，判空要写!== false - 不要在循环里反复调
handler()，它每次都会返回新实例；建议单例复用或注入到服务类中
排行榜缓存如何与业务数据联动更新
用户得分变化（如完成任务、被点赞）不能只改数据库，必须同步更新 Redis ZSET，否则缓存和 DB 不一致。关键点是「原子性」和「失败兜底」：
立即学习“PHP免费学习笔记（深入）”；
- 得分变更逻辑必须包裹在事务中：先更新 DB，再更新
ZADD；若 DB 更新成功但 Redis 失败，需记录日志并触发补偿任务 - 避免用
ZINCRBY直接累加——如果用户首次上榜，ZINCRBY会创建新成员，但初始分可能应为固定值（如注册送 10 分），此时该用ZADD显式设分 - 每日/每周榜单需定时清空旧 ZSET 并重建：用
$redis->del('rank:week')，不要用FLUSHDB，以免误删其他缓存 - 用户注销或封禁时，务必调
$redis->zRem('rank:week', $user_id)，否则僵尸 ID 会一直占位
排行榜接口性能瓶颈常出在哪几个地方
看似简单的 ZREVRANGE 接口，上线后容易在三个环节卡住：
- 没加
WITHSCORES选项却想同时取 ID 和分数——结果只拿到 ID 数组，还得回库查分数，N+1 查询直接拉垮 - 前端请求带了无效参数如
?page=1&limit=1000，后端没校验就传给zRevRange($key, 0, 999)，大范围扫描导致 Redis 阻塞 - 没设置 ZSET 过期时间，长期累积几百万成员，
ZCARD和ZRANK耗时陡增；必须用$redis->expire('rank:week', 3600 * 24 * 7)主动过期 - 排行榜页面未做本地缓存（如 HTTP Cache-Control），导致每刷一次就打一次 Redis，QPS 翻倍却不增收益
真正难的不是写对一行 zAdd，而是让每个得分变更都可靠落地、每次查询都可控边界、每份缓存都有明确生命周期。ZSET 很快，但人一松懈，慢的永远是逻辑缝里的那几毫秒。
