凉了呀，面试官叫我设计一个排行榜。

这是why哥的第89篇原创文章

前两天，有一个读者给我发了一张图片。

我问：发什么肾么事了？

因而有了这样的对话：

.png)

他发的图，就是微信运动步数排行榜的截图：

其实扯了这么多，这就是个常见的面试场景题：如何设计一个排行榜？

这个题吧，其实就是考你面试准备范围的广度，见过就会答，没见过...就难说了。

固然，若是你在实际业务中作过排行榜，那么这题正中下怀，你也不要笑出声来，场景题面试官是会给你思考时间的。

因此你不要张口就来，你只须要眉头稍稍一皱，给面试官说：这题我想一想啊。

而后稍微组织一下语言，说出来就行。

此次的文章，就带着你们分析一下“排行榜”这个场景题，到底应该怎么作。

基于数据库

这个题，若是是真的以前没有碰见过，可能最容易进入你们视野的就是平时接触的最多的数据库了。

由于一想到“排行榜”，就想到了 order by。

一想了 order by，就想到了数据库。

一想到了数据库...

兄弟，你路就走窄了。

虽然我曾经就基于 MySQL 作过排行榜，由于当时是为了一个比赛临时搭建的服务，根本就没有引入 Redis。我评估了一下搭建 Redis 的时间和用 MySQL 直接开发的时间。

因而选择了 MySQL。

而让我选择 MySQL 的根本缘由仍是我已经知道进入决赛的队伍只有 10 支，也就是说个人排行榜表里面从始至终也只有 10 条数据。

选手提交代码以后，系统实时算分，而后更新排行榜表。

而后接口返回给前端页面下面这些数据，而下面这些数据都在一个表里面：

• 队伍按照历史最高分数排名
• 队伍名称
• 历史最高分数
• 最近一次提交得分
• 最近一次提交时间

前端每隔一分钟调用个人接口，相同分数，名次相同，因此我在接口里面用一条比较复杂的 sql 去查询数据库，上面的这些字段就都有了。

你看，排行榜确实是能够用 MySQL 来作的。

不必定非得上 Redis，记住一句话：脱离业务场景的方案设计，都是耍流氓。

可是这玩意和“万物皆对象”同样，别对着面试官说，这必定不是面试官想要听到的答案。

或者说，这只是想要听到的一部分回答。

这个回答能用的缘由是我给了一个具体的场景，用户量很是的小，怎么玩均可以。

甚至咱们不借助 MySQL 的排序，把数据查出来，在内存里面排序均可以。

可是若是，这是一个游戏排行榜，随着游戏玩家的增长，达到千万用户级别的话，这个方案确定是不行了。

固然，也许你会给我扯什么查询慢就加索引，数据量大就分库分表的方案。

怎么说呢，上面这句话是没有错的。

可是一旦数据量大起来了，这个方案其实就不是一个特别好的方案。

这问题，得从根上治理。

基于 Redis

这个场景其实就是在考察你对于 Redis 的 sorted set 数据结构的掌握。

sorted set，见名知意，就是有序集合的意思。

在 Redis 中它大概是长这样的：

前面的 sport:ranking:20210227 是 Redis 中的 key。

value 是一个集合，且能够看出这个集合是有序的。集合中的每个 member 都有一个 score，而后按照这个 score 进行降序排序。

须要注意的是，图片中的 score/member 不是我随便写的，官网上就是这样定义的：

https://redis.io/commands/zadd#sorted-sets-101

并且官网上说的是： score / member pairs。

因此我画图的时候，score 在前，member 在后。这可不是随便画的，虽然谁前谁后好像也不影响什么玩意。

另外一个须要注意的点是，虽然个人示意图中没有体现出来，可是在有序集合中，元素即 member 是不能够重复的，可是 score 是能够重复的。

这个很好理解，就好比 20210227 这一天的微信步数，我能够走 6666 步，你也能够走 6666 步，这个是不冲突：

可是，问题就随之而来了：当 member 的 score 同样的时候，member 是怎么排序的呢？

看一下来自官网的答案：

当多个元素具备相同的分数时，它们按照 lexicographically 进行排序。

哎呀，lexicographically 这个单词不认识。

不慌，你知道的 why哥还兼职教英文：

当分数同样的时候，按照字典序排序，因此上面的示意图 jay 在 why 以前。

接下来，看一下有序集合的操做函数，一共有 32 个：

我这里就不一个个的作 API 教学了，官网上已经写的很清楚了，若是对于不熟悉的命令，能够去官网上查看，都是有示例代码的。

https://redis.io/commands/zadd#sorted-sets-101

好比这个 ZADD 方法：

为了后面分享的顺利进行，我这里只讲几个须要用到的操做：

• 添加 member 命令格式：zadd key score member [score member ...]
• 增长 member 的 score 命令格式：zincrby key increment member
• 获取 member 排名命令格式：zrank/zrevrank key member
• 返回指定排名范围内的 member 命令格式：zrange/zrevrange key start end [withscores]

先看第一个：添加 member。

好比咱们把示意图中的数据添加到到有序集合里面去，语法是这样的：

• zadd key score member [score member ...]

意思是能够一次添加一对或者多对 score-member，好比下面这两个命令：

• zadd sport:ranking:20210227 10026 why
• zadd sport:ranking:20210227 10158 mx 30169 les 48858 skr 66079 jay

执行以后，返回的数字表明添加成功的 member 个数。

我用专门操做 Redis 的 RDM 可视化工具来查看插入的数据，和我本身画的示意图相差无几：

接着看第二个：增长 member 的 score

微信运动排行榜的数据是实时更新的。

目前 member 为 why 的步数是 10268，假设我吃完晚饭出门跑步去了，又跑了 5000 步。

这时得更新个人步数，就用 zincrby 命令，语法是这样的：

• zincrby key increment member

对应上面场景的执行命令是这样的：

• zincrby sport:ranking:20210227 5000 why

执行完成后，会返回 why 的步数，能够看到从 10026 变成了 15026 ：

同时因为个人步数增长，按照 score 倒序，也致使了排序的变化：

因此咱们只须要更新 score 就好了，至于排名的变化，Redis 会帮忙保证的。

而后看第三个命令：获取 member 排名

语法是这样的：

• 获取 member 排名：zrank key member
• 获取 member 排名：zrevrank key member

首先，排名都是 0 开始计算的。

zrank 是按照分数从低到高返回 member 排名。

zrevrank 是按照分数从高到低返回 member 排名。

好比如今要获取 jay 的排名，用 zrank 返回结果就是 4。

• zrank sport:ranking:20210227 jay

当用 zrevrank 时，jay 的排名就是 0：

• zrevrank sport:ranking:20210227 jay

因此，在微信步数排行榜的这个需求中，步数越多排名越靠前，咱们应该用 zrevrank。

第四个须要掌握的命令是：返回指定排名范围内的 member。

• zrange/zrevrange key start end [withscores] 返回指定排名范围内的 member

这个命令就很关键了。

zrange 是按照 score 从低到高返回指定排名范围内的 member。

zrevrange 是按照 score 从高到低返回指定排名范围内的 member。

在这里，我只演示 zrevrange 的命令。

好比我要获取步数排名前三的 member：

• zrevrange sport:ranking:20210227 0 2

这个命令有个可选参数：withscores

当带上这个参数以后，会返回对应 member 的 score：

你想，这不就是排行榜 top N 的场景吗？

假设我如今要获取全部用户的排名，怎么写呢？

以下：

• zrevrange sport:ranking:20210227 0 -1

这就是当前的微信步数排行榜，jay 步数最多，mx 步数最少。

咦，怎么回事，排行榜很久就出来了呢？

你想一想，讲完几个 API 操做，好像功能就实现了呢？

是的，确实是这样的，甚至咱们只须要这两个 API 就能完成排行榜的需求：

• zadd key score member [score member ...] 添加 member
• zrange/zrevrange key start end [withscores] 返回指定排名范围内的 member

好了，若是你们喜欢的话，感谢你们一键三连。本次的文章就到这里了...

那是不可能的。

索然无味的 API 文章多没有意思啊。

虽然前面的部分咱们已经能够基于 Redis 的有序集合加上几个简单的命令，就能够实现排行榜需求了。

可是前面只是铺垫，接下来，好戏才刚刚开始。

再次审视排行榜

上面的微信步数排行榜有个问题，你发现了吗？

就上面这个场景而言，全部人来看，看到的都是这样的排序：

而真实状况是，每一个人看见的数据排行数据来源本身的微信好友，而微信好友各不相同，因此看到的排行榜也各不相同。

这个特性，咱们并无体现出来。

咱们上面的场景更加相似于游戏排行榜，全部的人看到的全服排行榜都是同样的。

那么怎么保证咱们每一个人看到的各不相同呢？

你思考一下，该从什么角度去解决这个问题呢？

有序集合的 key 不一样，就获取到不一样的 value 集合。

咱们当前的 key 是 sport:ranking:20210227，里面只包含了某一天的信息。

只要咱们在 key 里面加上用户的属性就能够了，假设个人微信号是 why。

那么 key 能够设计为这样 sport:ranking:why:20210227。

这样，因为 key 里面多了用户信息，每一个人的 key 都各不相同，就像这样的：

对应的命令以下：

• zadd sport:ranking:why:20210227 10026 why 10158 mx 30169 les 48858 skr 66079 jay
• zadd sport:ranking:mx:20210227 7688 赵四 9688 刘能 10026 why 10158 mx 54367 大脚

why 和 mx 看到的都是各自好友某一天的微信步数排行榜。

只要把 key 设计好了，这个问题就迎刃而解了。

可是你仔细思考一下，真的就迎刃而解了吗？

这个问题，我在写初版的时候多是被猪油蒙蔽了双眼，没发现。

有种“只缘身在此山中”的味道，一心想着 Redis 了。

你想，若是每一个用户都有在redis有一个本身的排行榜，一个用户的分数更新的时候就须要对全部好友的zset更新，这多大的代价啊，对吧？

当以用户为纬度作排行榜的时候，就会出现排行榜巨多的状况，致使维护成本升高。

Redis能作，但不是最佳方案。

那么用什么方案去作呢？

我提个思路吧：

每一个用户看到的排行榜不同，咱们其实不用时时刻刻帮用户维护好排行榜。

维护好了，用户还不必定来看，出力不讨好的节奏。

因此还不如延迟到用户请求的阶段。

当用户请求查看排行榜的时候，再去根据用户的好友关系，循环获取好友的步数，生成排行榜。

具体方案，你们本身思考一下吧。

另外多说一嘴，前段时间不是微信支持了修改微信号吗，赢得一大片叫好声。

其实我当时认真的想了一下，从技术上的实现来讲这个需求到底有多难。

我不知道有没有历史技术债务在里面。

可是就说当前这个场景，key 里面包含了微信号，注意是微信号，不是微信昵称。

由于在设计之初，产品打包票说：放心，微信号绝对全局惟一，一旦肯定，不可变动。

结果呢，如今要变化了。

产品屁颠屁颠的说：怎么实现我无论，这个需求用户呼吁很大，赶忙上线。

你说，对这些相似场景的冲击有多大？

其实冲击也不算特别大，一个字段的变化而已。

可是，微信 14 亿用户啊。

一个简单的需求，涉及到这个体量以后，就一句话：

量变引发质变。

好了，好了，扯远了。说回来。

当我把目光再次放到微信排行榜上的时候，我发现，其实我只是给了一个阉割版的排行榜。

是的，咱们如今能够获取到 why 的当前步数是 1680 步，当前排名是 814 名。

好比仍是沿用上面的例子，假设如今要获取个人微信好友 jay 的微信步数排行榜状况。

先获取 jay 的名次：

• zrevrank sport:ranking:why:20210227 jay

名次为 0，程序里面能够对其进行加一操做。就是第一名了。

接着获取 jay 的今日步数：

• zscore sport:ranking:why:20210227 jay

66079，步数也有了。

如今咱们知道了：why 的好友 jay 今日运动步数 66079 步，在 why 的微信好友中排第一名。

可是你仔细看，这上面我还漏了两个字段：

• 微信头像
• 朋友点赞个数

两个字段应该怎么放呢？

放数据库里面固然能够，可是咱们主要仍是说一下 Redis 的解决方案。

这个时候其实咱们想要存储的是 User 对象，对象里面有这几个字段：昵称、头像图片连接、点赞数、步数。

你说，这个用 Redis 的啥数据结构来存？

可不就得用 Hash 结构了吗。

Hash 结构一样涉及到 key 和 value，那么它们分别是什么呢？

key 就是咱们的有序集合的 key 后面再加上好友昵称，好比这样的：

对应的命令是这样的：

• hmset sport:ranking:why:20210227:jay nickName jay headPhoto xxx likeNum 520 walkNum 66079

执行完成以后，在 RDM 里面看起来是这样的：

当后续有更多的赞的时候，须要调用更新命令更新 likeNum：

• hincrby sport:ranking:why:20210227:jay likeNum 500

执行完成以后点赞数就会变成 1020：

这样，排行榜上的全部字段咱们都能获取到了，微信排行榜就说完了。

呃......

怎么感受仍是 API 教学呢？

不得劲，换个其余的。

最近七天排行榜怎么弄？

前面咱们说的都是每日排行榜。

假设面试官要求咱们提供一个最近七天、上一周、上一月、上个季度、这一年排行榜啥的，又该怎么搞呢？

其实这仍是在考察你对于 Redis 有序集合 API 的掌握程度。

也就是这个 API：

• zinterstore/zunionstore destination numkeys key [key ...] [weights weight [weight ...]] [aggregate sum|min|max] 获取交集/并集

这个 API 看起来有点复杂，不要怕，一个个的讲：

• zinterstore/zunionstore其实就是交集/并集
• destination 将交集/并集的结果保存到这个键中
• numkeys 须要作交集/并集的集合的个数
• key [key ...] 具体参与交集/并集的集合
• weights weight [weight ...] 每一个参与计算的集合的权重。在作交集/并集计算时，每一个集合中的 member 会把本身的 score 乘以这个权重，默认为 1。
• aggregate sum|min|max 对于各个集合中的相同元素是 sum(求和)、min(取最小值)仍是max(取最大值)，默认为 sum。

拿最近七天举例，咱们随便搞点数据进来，你能够直接粘过去玩：

• zadd sport:ranking:why:20210222 43243 why 2341 mx 8764 les 42321 skr
• zadd sport:ranking:why:20210223 57632 why 24354 mx 4231 les 43512 skr 5341 jay
• zadd sport:ranking:why:20210224 10026 why 12344 mx 54312 les 34531 skr 43512 jay
• zadd sport:ranking:why:20210225 54312 why 32451 mx 23412 les 21341 skr 56321 jay
• zadd sport:ranking:why:20210226 3212 why 63421 mx 53652 les 45621 skr 5723 jay
• zadd sport:ranking:why:20210227 5462 why 10158 mx 30169 les 48858 skr 66079 jay
• zadd sport:ranking:why:20210228 43553 why 4451 mx 7431 les 9563 skr 8232 jay

能够看到咱们一共有 7 天的数据：

并且须要注意的是 20210222 这一天是没有 jay 的数据的。

如今咱们要求出最近 7 天的排行榜，就用下面这行命令，命令有点复杂，可是对着命令格式看，仍是很清晰的：

• zunionstore sport:ranking:why:last_seven_day 7 sport:ranking:why:20210222 sport:ranking:why:20210223 sport:ranking:why:20210224 sport:ranking:why:20210225 sport:ranking:why:20210226 sport:ranking:why:20210227 sport:ranking:why:20210228 weights 1 1 1 1 1 1 1 aggregate sum

这条命令后面的 weights 和 aggregate 都是能够不用写的，有默认值，我这里为了避免隐藏数据，都写了出来。

执行完成后，能够看到多了一个 key，里面放的就是最近 7 天的数据汇总：

上面用的是并集，若是咱们的要求是对最近 7 天，天天都上传运动数据的人进行排序，就用交集来算。

命令和上面的一致，只是把 zunionstore 修改成 zinterstore 便可。

另外为了有对比，合并以后的队列名称也修改一下，命令以下：

• zinterstore sport:ranking:why:last_seven_day_zinterstore 7 sport:ranking:why:20210222 sport:ranking:why:20210223 sport:ranking:why:20210224 sport:ranking:why:20210225 sport:ranking:why:20210226 sport:ranking:why:20210227 sport:ranking:why:20210228 weights 1 1 1 1 1 1 1 aggregate sum

从执行结果能够看出来，因为 jay 同窗在 20210222 这一天没有上传运动数据，因此取交集的时候没有他了：

知道最近 7 天的作法了，咱们又有每一天数据，上一周、上一月、上个季度、这一年排行榜啥的不都是这个套路吗？

呃......

怎么感受仍是 API 教学呢？

仍是不得劲，再换个其余的。

亿级用户排行榜

王者荣耀，妥妥的亿级用户吧。好比我想看看我在亿级用户中排多少名，因而我打开了游戏，二十多分钟（玩了一局）以后我终于找到排行榜的位置。

结果，未上榜：

我这个千年老夫子，固然是未上榜了。

就算真的有排名了，排名好几千万，8 位数字，在页面上也很差放呀。

可是假设如今的需求就是要查询用户的全服排名，怎么查？

我瞎说一个我能想到的基于 Redis 的第一版方案，注意是我瞎想的，实际作起来确定是异常复杂的方案。

我是怎么想的呢？

我就寻思，通常面试遇到什么千万条数据、几个 G 文件、上亿的数据啥的，首先想到的方案就是分而治之。

这个亿级用户排行榜的需求也得用分治的思想。

王者一共 8 个段位：

• 一、倔强青铜
• 二、秩序白银
• 三、荣耀黄金
• 四、尊贵铂金
• 五、永恒钻石
• 六、至尊星耀
• 七、最强王者
• 八、荣耀王者

因此咱们能够有 8 个桶。

这个桶能够是一个 Redis 里面的 8 个不一样的 key，甚至能够是 8 个 Redis 里面各一个 key，看面试官给你的经费是多少，钱多就可劲造。

以下图所示：

解释一下上面的图片中 score 为 8588 是怎么来的。

首先咱们用 Redis 的有序集合，那么咱们就得给每一个 member 一个 score。

因此，每一个用户在桶里面都一个通过公式计算后得出的积分。

好比why哥如今的段位就是星耀，假设计算出来的分数是 8588。

那么如今要算why哥在全服的排名就很好算了：

写程序的时候是能够知道我如今的段位是星耀，那么直接去星耀的桶里面，用 zrevrank 计算出当前桶里面的排名，假设为 n。

而后再经过 zcard 这个 O(1) 的命令获取到，前面的桶，也就是最强王者和荣耀王者这两个桶的集合大小，分别为 y 和 x。

那么why哥的全服排名就是 n+y+x。

因此获取任何一个用户的全服排名，就是看他在本身的桶里面的排名加上前面桶里面的元素个数便可。

并且如今要计算全服 top 100 就很容易了嘛。

直接取最前面的桶，也就是荣耀王者里面的前 100 个就完事了。

搞定。

等等，真的搞定了吗？

思路是对了，可是对于亿级用户只分 8 个桶未免太少了吧？

那就继续分桶呗，别忘了，每一个段位里面还有小段位的。

好比星耀，里面就有星耀五到星耀一五个小段位，青铜三到青铜一三个小段位。

所有算上就是 27 个桶。

可是，27 个桶也少。

那么星耀二到星耀一还须要五颗星、青铜三到青铜二要三颗星才行呢。

这样算下来，就是 160 个桶。

160 个桶仍是不够？

额。。。

推翻重来，直接把段位加上各类其余条件换算成积分，而后按照积分来拆分：

这样，想怎么拆分数段都行、拆多细都行。

完美。

等等，真的完美吗？

你看个人积分范围，都划分的很是的均匀。

按照段位拆分，有些菜鸡选手，打了两把以为没意思，骂骂咧咧的退出游戏，就一直留在了青铜段位。

因此青铜段位的选手确定是远大于荣耀王者的。

因此，实际状况下，用户的落点其实并非均匀的。

怎么办？

这个时候就须要进行数据分析，经过一系列的高数、几率、离散等知识去作个桶大小的预估。

啊，这玩意就超纲了啊。

那就告辞，收工。

技术以外的考虑

作一个排行榜好像是一个很简单的事情。

可是其实否则，特别是推荐类的排行榜，须要避免马太效应：

好比做者推荐榜单，被推荐到前面的做者，曝光度很高。即便输出质量降低，可是仍是很容易得到更多的关注。

位于榜单尾部的做者就很没有参与感。

因而两极分化就出现了，马太效应就来了。

对于这种状况怎么处理呢？

里面就涉及到一个复杂的计算公式了，好比掘金社区的掘力值，用于消息流推荐和做者榜单：

https://juejin.cn/book/6844733795329900551/section/6844733795380232206

因此千万不要错误的觉得排行榜是一个很是简单的需求，这里面涉及到一些很是复杂的算法。

最后说一句

感谢你们的阅读。

才疏学浅，不免会有纰漏，若是你发现了错误的地方，能够在后台提出来，我对其加以修改。