Redis ZSET 排行榜完整工作流：加分、TOP榜、我的排名和周榜归档

很多业务一开始做排行榜时，需求看起来很简单：用户加分后，把前 100 名展示出来，再给当前用户看一下“我的排名”。但真正写到线上，很快会遇到几个细节：分数怎么累加、TOP 榜怎么分页、用户自己的排名怎么查、同分怎么排、周榜结束后怎么归档。

这篇文章按完整工作流来拆 Redis ZSET 排行榜。我们不只看一条命令，而是从 Key 设计、写入、查询、分页、同分规则到周期榜单收尾，整理成一套可以直接落地的路线。

目标和边界：先把排行榜类型定清楚

先把边界定清楚。本文讨论的是“分数越高排名越靠前”的排行榜，比如积分榜、活动榜、答题榜、贡献榜。数据量可以从几千到几百万，读多写也不少，需要快速拿到 TOP 列表和某个用户的名次。

不在本文范围里的场景有两类：第一类是复杂多维排序，例如分数、等级、地区、会员等级一起影响排名；第二类是强审计积分系统，例如每一分都要追溯流水。这些仍然可以用 ZSET 做展示层，但需要额外的业务表保存明细。

先说结论：ZSET 负责排名，业务负责规则

Redis ZSET 最适合承担排行榜的“排序视图”：member 放用户标识，score 放用于排名的数值。加分用 ZINCRBY，TOP 榜用 ZREVRANGE，我的名次用 ZREVRANK，我的分数用 ZSCORE。

但是有一点要提前记住：ZSET 只负责按 score 排序。同分时到底按时间、用户编号，还是并列名次，要由业务提前定规则。规则定不清，后面页面展示和用户反馈都会变得很难解释。

全流程总览：从加分到分页展示

下面这张图是最常见的排行榜主流程：用户行为产生分数，写入 ZSET 后，页面可以同时拿 TOP 榜、我的排名和分页数据。

阶段 1：设计排行榜 Key 和 member

目标：让每个榜单都有明确边界。一个推荐的 Key 结构是：

rank:{biz}:{period}:{id}

示例：
rank:activity:week:2026-W25
rank:course:day:2026-06-15
rank:game:season:S12

biz 表示业务类型，period 表示日榜、周榜、赛季榜，id 表示具体周期。这样做的好处是查询简单，归档也简单。周榜结束后，只要处理这一周的 Key，不会影响日榜或总榜。

member 建议放稳定的用户 ID，例如 user:10086。如果你的页面需要昵称、头像、等级，不要把这些资料塞进 ZSET。排行榜只保存排名视图，用户资料从缓存或数据库批量补齐。

阶段 2：写入分数和读取 TOP 榜

目标：用户产生积分变化后，能快速反映到榜单里。最直接的写法是用 ZINCRBY 累加分数。

ZINCRBY rank:activity:week:2026-W25 10 user:10086
ZINCRBY rank:activity:week:2026-W25 5 user:10087

读取前 10 名时，用倒序读取，因为我们要分数高的排在前面：

ZREVRANGE rank:activity:week:2026-W25 0 9 WITHSCORES

检查点有两个：第一，分数必须是业务确认后的结果，不要把未支付、未审核、可撤销的分数直接写入正式榜；第二，页面展示最好把 member 批量转成用户资料，避免循环查数据库。

阶段 3：查询我的排名和分页数据

目标：用户打开页面时，既能看到榜单，也能知道自己在哪。我的排名可以这样查：

ZREVRANK rank:activity:week:2026-W25 user:10086
ZSCORE rank:activity:week:2026-W25 user:10086

ZREVRANK 返回的是从 0 开始的下标，展示给用户时要加 1。如果返回空值，说明这个用户还没上榜，可以展示“暂未上榜”或“完成一次任务后参与排名”。

分页本质上还是范围查询。比如每页 20 条，第 3 页可以换算成起止位置：

page = 3
size = 20
start = (page - 1) * size
stop = start + size - 1

ZREVRANGE rank:activity:week:2026-W25 40 59 WITHSCORES

这里的检查点是：分页不要一次性把全榜拉回应用层再截取。ZSET 已经提供了范围读取，应用层只负责计算下标和补齐用户资料。

阶段 4：处理同分、周榜归档和过期清理

排行榜上线后，最容易被忽略的是同分规则和周期榜收尾。下面这张图把这两个动作放到同一条工作流里：先确定同分排序，再查询排名，周榜结束后归档并设置过期时间。

同分规则怎么定

ZSET 的 score 相同时，还会按 member 的字典顺序参与排序。这个规则是确定的，但不一定符合你的业务。例如活动榜希望“先达到该分数的人排前面”，那就不能只把用户 ID 当 member 然后直接展示。

常见做法有两种：

• 并列展示：同分用户展示同一名次，页面文案说明“同分并列”。这种做法简单，但分页和奖励边界要提前定义。
• 组合分数：把主分数和时间序号组合成一个可排序分数，例如主分数越高越靠前，同分时更早完成的人更靠前。要注意数值范围，避免超过安全整数精度。

如果业务对奖励边界很敏感，我更推荐把积分流水和最终发奖名单落到数据库，再用 ZSET 做实时展示。这样既有实时榜，也有可审计的最终结果。

周榜如何归档

周榜结束时，不建议立刻删除旧 Key。可以先把前 N 名写入历史榜单表，或者复制一份结果到只读缓存，再给旧 Key 设置过期时间：

EXPIRE rank:activity:week:2026-W25 604800

这样用户在活动结束后一段时间内仍能查看结果，后台也有时间完成发奖、申诉和数据核对。等窗口期结束，Redis 会自动清理旧榜，内存压力也可控。

我的推荐流程

如果从零实现一个 Redis 排行榜，我会按下面顺序推进：

1. 先写清楚榜单类型：日榜、周榜、总榜，还是活动榜。
2. 确定 Key 结构，保证不同活动和周期互不影响。
3. 确定 member 只放稳定用户 ID，用户资料走批量补全。
4. 用 ZINCRBY 写分，用 ZREVRANGE 读 TOP 榜。
5. 用 ZREVRANK 和 ZSCORE 做“我的排名”。
6. 提前确认同分和奖励边界，不要等用户反馈后再改。
7. 周期结束后归档结果，再给旧榜设置过期时间。

容易踩坑

• 只设计 TOP 榜，不设计我的排名：页面会多一次全榜扫描，数据量大时很慢。
• 把昵称头像放进 member：用户改名后榜单数据会混乱，补资料也麻烦。
• 同分规则不明确：奖励边界最容易产生争议，必须提前写进需求。
• 周期 Key 不带日期：日榜、周榜、历史榜会互相覆盖。
• 旧榜永不过期：活动多了以后，Redis 内存会被历史数据慢慢吃掉。

速查表

总结

Redis ZSET 做排行榜的核心并不复杂：score 排序，member 标识用户，范围查询拿榜单，排名查询找个人位置。真正决定系统是否好用的，是 Key 设计、同分规则、分页策略和周期收尾。

把这几件事提前设计好，排行榜就不是几条零散命令，而是一条完整工作流：加分进入 ZSET，页面读取 TOP 榜和我的排名，周期结束后归档并清理旧 Key。这样既能支撑实时展示，也能给后续运营和发奖留出清楚的边界。