Redis排行榜实战：从崩溃到毫秒级响应

从一个崩溃的排行榜说起你是一个游戏服务器开发。游戏上线第一天策划跑过来说“我们要一个战力排行榜。实时的。玩家打开排行榜能看到全服前100名。还能看到自己排第几。”你想了想觉得不难。数据库里有每个玩家的战力值。查一下不就行了SELECTplayer_id,player_name,powerFROMplayersORDERBYpowerDESCLIMIT100;上线了。没问题。第二天在线人数涨到了10万。每个玩家每次升级、换装备、强化武器都会改变战力值。每秒有几千次战力更新。每次更新之后排行榜就变了。玩家打开排行榜就要执行一次上面那条SQL。每秒几百次排行榜查询。每次查询都要对几十万行数据做全表排序。数据库的CPU飙到了100%。查询延迟从10毫秒涨到了3秒。玩家打开排行榜转三秒钟的菊花才看到结果。然后策划又跑过来了“我们还要竞技场排名、等级排名、充值排名、公会排名、活动积分排名……一共12个排行榜。”你看着数据库监控面板上那条快要冲出屏幕的CPU曲线陷入了沉默。一、为什么数据库扛不住排行榜排行榜的本质是什么一个有序的列表。按某个分数从高到低排列。数据库当然能做排序。但数据库的排序是临时的——每次查询都重新排一遍。ORDER BY power DESC这条语句每执行一次数据库就要把所有玩家的战力值拿出来排一遍序取前100个。就算有索引排序的代价也是O(N log N)。N是玩家总数。10万玩家每次排序要比较几十万次。而且排行榜的查询频率极高。每个玩家打开排行榜界面就是一次查询。万人同时在线可能每秒几百次查询。几百次 × O(N log N) 数据库爆炸。更要命的是排行榜还有一个需求查询某个玩家的排名。“我排第几”这个查询在数据库里更贵。你得数一数有多少人的战力比你高SELECTCOUNT(*)FROMplayersWHEREpower你的战力;全表扫描。O(N)。每次查询都扫一遍全表。排行榜需要的是一种天生就有序的数据结构。不是每次查询都临时排序而是数据插入的时候就自动排好序。这正是Redis的Sorted Set有序集合干的事。二、Sorted Set天生为排行榜而生2.1 它是什么Redis的Sorted Set简称ZSet是一个集合里面的每个元素都关联一个分数score。元素按分数自动排序。你可以把它想象成一个自动排序的花名册。每个人有一个名字member和一个分数score。你往花名册里加人、改分数花名册自动按分数从低到高排列。你随时可以问“前10名是谁”“张三排第几”“分数在1000到2000之间的有哪些人”所有这些操作都是O(log N)的。不管花名册里有1万人还是100万人查询速度几乎一样。2.2 底层原理跳表Sorted Set的底层是一个叫**跳表Skip List**的数据结构。想象一条长长的链表所有元素按分数从小到大排列。你要找一个元素得从头开始一个一个往后找。O(N)。太慢了。跳表的做法是在链表上面加几层快车道。第一层底层所有元素一个挨一个。第二层每隔几个元素抽一个出来组成一条更稀疏的链表。第三层再从第二层里每隔几个抽一个。第四层继续抽……查找的时候从最高层开始。在高层的快车道上快速跳过大段元素找到大致范围后下降到下一层继续精确查找。就像坐地铁。快线跳过大站到了附近再换慢线一站一站地找到目的地。跳表的查找、插入、删除都是O(log N)。而且实现比平衡二叉树简单得多。Redis的作者antirez选择跳表而不是红黑树就是因为跳表更简单、更容易调试、并发友好。2.3 为什么O(log N)这么重要100万玩家的排行榜。数据库排序O(N log N) ≈ 2000万次比较。跳表查询O(log N) ≈ 20次比较。差了100万倍。20次比较在现代CPU上大约需要几百纳秒。加上Redis的网络开销一次排行榜查询大约1毫秒。从3秒到1毫秒。这就是选对数据结构的威力。三、用Redis实现排行榜手把手教学3.1 创建排行榜ZADD power_rank 85000 player:1001 ZADD power_rank 92000 player:1002 ZADD power_rank 78000 player:1003 ZADD power_rank 105000 player:1004 ZADD power_rank 88000 player:1005ZADD命令往有序集合power_rank里添加元素。每个元素有一个分数和一个成员名。分数是战力值。成员名是玩家ID。执行完之后Redis内部自动按分数排好了序。不需要你手动排。3.2 更新分数玩家1003换了一把神器战力从78000涨到了120000。ZADD power_rank 120000 player:1003同样的ZADD命令。如果成员已存在就更新分数。Redis自动把player:1003从原来的位置移到新的位置。O(log N)。100万玩家也只需要20次比较。3.3 查询前100名ZREVRANGE power_rank 0 99 WITHSCORESZREVRANGE按分数从高到低取排名第0到第99的元素前100名。WITHSCORES表示同时返回分数。返回结果1) player:1003 120000 2) player:1004 105000 3) player:1002 92000 4) player:1005 88000 5) player:1001 85000O(log N M)。N是总人数M是返回的数量100。几乎是瞬间完成。3.4 查询某个玩家的排名“我排第几”ZREVRANK power_rank player:1005返回3从0开始计数所以实际排名是第4名。O(log N)。一次跳表查找。3.5 查询某个玩家的分数ZSCORE power_rank player:1005返回88000。O(1)。因为Redis内部除了跳表之外还维护了一个哈希表可以直接通过成员名查分数。3.6 查询某个排名范围“我想看第50名到第60名。”ZREVRANGE power_rank 49 59 WITHSCORESO(log N M)。跟查前100名一样快。3.7 查询某个分数范围“战力在10万到20万之间的有多少人”ZCOUNT power_rank 100000 200000O(log N)。四、实战中的设计细节基本操作很简单。但真正上线的排行榜有很多细节需要处理。4.1 分数相同怎么办两个玩家战力都是85000。谁排前面Redis的Sorted Set在分数相同时按成员名的字典序排列。player:1001排在player:1002前面。但这不是你想要的。你可能想要先到先得——谁先达到这个战力谁排前面。解决方案把时间戳编码进分数里。实际分数 战力值 * 10000000000 (9999999999 - 时间戳)战力值是主排序依据。时间戳是次排序依据。时间戳取反是因为先到的时间戳更小取反后更大排名更靠前。比如玩家A战力85000时间戳1000。分数 85000 * 10^10 (10^10 - 1000) 850000009999999000玩家B战力85000时间戳2000。分数 85000 * 10^10 (10^10 - 2000) 850000009999998000玩家A的分数更大排名更靠前。先到先得。注意Redis的分数是double类型有效精度大约15-16位十进制数。上面的编码方式需要确保总位数不超过15位否则会丢失精度。4.2 排行榜太大怎么办100万玩家的排行榜每个元素大约占100字节成员名分数跳表指针。总共约100MB。Redis是内存数据库。100MB不算什么。但如果有12个排行榜呢1.2GB。如果每个排行榜都是100万人呢可能有些浪费。大部分玩家根本不关心自己排第89万名。解决方案只保留前N名。-- 更新分数后裁剪排行榜只保留前10000名 ZADD power_rank 85000 player:1001 ZREMRANGEBYRANK power_rank 0 -10001ZREMRANGEBYRANK删除排名靠后的元素。只保留前10000名。排名10000之外的玩家怎么办告诉他你的排名在10000名之外就行了。或者用数据库做一次粗略的估算。4.3 历史排行榜“上周的排行榜是什么样的”Redis的Sorted Set是实时的。分数一更新排名就变了。没有历史记录。解决方案定期快照。每天凌晨把当前排行榜复制一份ZUNIONSTORE power_rank:2024-01-15 1 power_rank EXPIRE power_rank:2024-01-15 604800 -- 保留7天ZUNIONSTORE把一个有序集合复制到另一个key。EXPIRE设置过期时间。这样你就有了每天的排行榜快照。玩家可以查看历史排名。4.4 跨服排行榜游戏有10个服务器。每个服务器有自己的排行榜。现在要做一个全服排行榜。方案一合并。定期把10个服务器的排行榜合并到一个全服排行榜里ZUNIONSTORE global_rank 10 power_rank:s1 power_rank:s2 ... power_rank:s10 AGGREGATE MAXZUNIONSTORE支持合并多个有序集合。AGGREGATE MAX表示同一个成员取最大分数。方案二每个服务器直接写全服排行榜。所有服务器连同一个Redis实例或者Redis Cluster直接往同一个key里写。这种方案实时性更好但需要处理并发和网络延迟。4.5 周期性排行榜“本周竞技场排名”。每周一重置。-- 周一凌晨执行 -- 1. 保存上周排行榜 RENAME arena_rank arena_rank:last_week EXPIRE arena_rank:last_week 604800 -- 2. 新的一周排行榜从空开始 -- 不需要额外操作新的ZADD会自动创建新的key或者用带日期的keyZADD arena_rank:week:2024-03 score member每周用不同的key。旧的key设置过期时间自动删除。五、性能数据让我给你一些实际的性能数据。单个Redis实例普通服务器8核CPU操作QPS平均延迟ZADD更新分数10万/秒1msZREVRANGE查前100名5万/秒1msZREVRANK查排名10万/秒1msZSCORE查分数15万/秒0.5ms100万元素的有序集合操作耗时ZADD~10微秒ZREVRANK~10微秒ZREVRANGE 0 99~15微秒内存占用~100MB对比MySQL有索引操作耗时UPDATE ORDER BY更新查排名~50-200毫秒SELECT TOP 100 ORDER BY~10-50毫秒Redis比MySQL快1000到10000倍。六、一个完整的排行榜服务让我把所有东西串起来画一个完整的架构。玩家战力变化 ↓ 游戏服务器 ↓ ├── 写MySQL持久化异步 │ └── 写Redis ZADD实时排名 ↓ power_rank (Sorted Set) ↓ ┌───────┼───────┐ ↓ ↓ ↓ 查前100 查排名 查分数 ZREVRANGE ZREVRANK ZSCORE ↓ ↓ ↓ └───────┼───────┘ ↓ 返回给客户端写入路径玩家战力变化 → 游戏服务器同时写MySQL和Redis。MySQL负责持久化万一Redis挂了数据不丢。Redis负责实时排名。读取路径客户端请求排行榜 → 游戏服务器查Redis → 返回结果。不碰MySQL。容灾Redis挂了怎么办从MySQL重建排行榜。写一个脚本把MySQL里所有玩家的战力读出来批量ZADD到Redis里。100万玩家大约需要几秒钟。一致性MySQL和Redis的数据可能短暂不一致比如写MySQL成功了但写Redis失败了。对排行榜来说短暂的不一致是可以接受的。排名差一两位玩家感知不到。如果需要强一致可以用消息队列来保证最终一致性。七、不只是战力排行榜同样的模式可以套用到几乎所有排行榜等级排行榜分数 等级 × 10^10 经验值。等级相同时按经验值排。充值排行榜分数 累计充值金额。竞技场排行榜分数 积分。每周重置。活动排行榜分数 活动积分。活动结束后冻结。伤害排行榜副本Boss战中实时更新每个玩家的伤害输出。分数 累计伤害。副本结束后结算奖励。公会排行榜成员不是玩家是公会。分数 公会总战力或公会等级。好友亲密度排行榜每个玩家有一个自己的有序集合成员是好友ID分数是亲密度。所有这些排行榜底层都是同一个东西Redis Sorted Set。一个ZADD一个ZREVRANGE一个ZREVRANK。三个命令撑起了整个游戏的排名体系。最后排行榜是游戏里最简单的功能之一。但它也是最容易做错的功能之一。用数据库做排行榜就像用菜刀砍树。能砍但砍几下菜刀就废了。用Redis的Sorted Set做排行榜就像用电锯。嗡的一声树就倒了。不是你的代码写得不好。是你选的工具不对。选对了工具排行榜就是三行命令的事。选错了工具排行榜就是三天三夜的噩梦。Redis的Sorted Set就是为排行榜而生的工具。跳表在底层默默地维护着秩序。每一次分数更新跳表用O(log N)的时间把元素放到正确的位置。每一次排名查询跳表用O(log N)的时间给出精确的答案。100万玩家20次比较1毫秒响应。玩家打开排行榜看到自己的名字在第1527名。他笑了笑关掉排行榜继续去刷怪升级。他不知道在这一瞬间一个跳表在几百纳秒内完成了一次精确的定位。他不需要知道。他只需要知道排行榜是实时的是准确的是瞬间就能打开的。这就够了。