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

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

我问：发什么肾么事了？

于是有了这样的对话：

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

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

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

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

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

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

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

基于数据库

这个题，如果是真的之前没有遇见过，可能最容易进入大家视野的就是平时接触的最多的数据库了。

因为一想到“排行榜”，就想到了 order by。

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

一想到了数据库...

兄弟，你路就走窄了。

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

于是选择了 MySQL。

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

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

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

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

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

你看，排行榜确实是可以用 MySQL 来做的。

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

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

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

这个回答能用的原因是我给了一个具体的场景，用户量非常的小，怎么玩都可以。

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

但是如果，这是一个游戏排行榜，随着游戏玩家的增加，达到千万用户级别的话，这个方案肯定是不行了。

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

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

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

这问题，得从根上治理。

基于 Redis

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

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

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

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

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

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

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

而且官网上说的是： 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 方法：