背景

现如今每个互联网平台都会提供一个排行版的功能，供人们预览最新最有热度的一些消息，比如百度：

再比如微博：

我们要知道，这些互联网平台每天产生的数据是非常大，如果我们使用MySQL的话，db实现小时、天、周、月的排行榜，难度及其大，而且表结构的设计也非常难，再者db也打不住这么大的并发量。

技术方案

所以高并发实时的排行榜天然适合用redis来实现。

那我们该用什么数结构呢？

正好，redis中有一个zset数据结构，刚好可以用来排序，下面说一下整体思路：
整体的技术实现是采用redis的zset来实现，每条微博是一个member，每条微博的热度值为一个score。
这里的score就和好评判了，每个平台有自己的阶段规则，比如给点赞、评论、转发，分别给出不同的评分权重，根据用户的行为来给这些一条数据加上不同的分数，然后排序。

好的，解决了数据选型以后，还需要思考：那如何把小时、天、周、月的数据，实时计算呢？

我们可能把所有数据放在一个Key里边吧，这样会造成redis的大key,导致性能受到影响，所以我们可以
以小时为单位，即每个小时为一个zset近24小时，就合并24个zset近7天，就合并247个zset，近30天（月），就合并2430个zset，这样我们得到了最近一小时、最近一天、最近七天的排行榜，乔碧萝看了都直呼哥哥好屌！

有了上面的思路以后我们再继续思考一个问题：如何实现以每个小时为一个zset？如何把时间切割为小时？

其实：先把当前的时间转换为为毫秒的时间戳，然后除以一个小时，即当前时间T/10006060=小时key，然后用这个小时序号作为zset的key。
例如：
2020-01-12 15:30:00=1578814200000毫秒转换小时key=1578814200000/1000*60*60=438560

2020-01-12 15:59:00=1578815940000毫秒转换小时key=1578815940000/1000*60*60=438560
2020-01-12 16:30:00=1578817800000毫秒转换小时key=1578817800000/1000*60*60=438561
剩下的以此类推有了这个思路，剩下的工作就是每次某个微博热度有变化，先计算当前的小时key，然后把当前的微博作为member，热度值作为score，加入zset中。

这里的操作其实也很好理解，就是一个简单的计算机的“取模”运算，同一个小时转化为毫秒以后不断取整以后，整数部分一定相同！

总结

至此我们已经知道了微博、百度得排行版是如何实现的，举一反三，大多大数据量下的排序我们都可以参考此实现方案！