如何应对突增的请求,实时更新排名,微博热搜

Published: 03 Jul 2020 Category: arch

一、如何应对突增的请求?

二、如何做到实时排名更新?

2.1 基于Redis实现

可以基于redis的sorted set来实现。

2.1.1 复合权重排序

同分数下先到达该分数的用户需要排在前面。因为redis有序集合的score是double类型,我们可以对已捐积分和用户开销表中该用户记录的最后修改时间做一个复合的权重。可以是 带时间戳的分数 = 实际分数*10000000000 + (9999999999 – timestamp). 如果权重值double会越界,那么可以适当对timestamp做裁剪,比如只取月后面的时间。

2.2 基于桶排序实现

如果分数是确定的,比如在1-5000,那么可以按照分数拆分成桶,把用户按照分数放入对应的分数桶中。

要查询实时排行榜topN只需要把分数高的前面几个桶合起来展示就可以了。

2.3 基于堆来实现(优先队列)

这样始终能快速找到最小或最大的那个值,或者返回整个堆(堆的大小=k),解决Top K问题。

优先队列还可以用来

  1. 合并有序的小文件:

假设我们有 100 个小文件,每个文件的大小是 100MB,每个文件中存储的都是一行行有序的字符串。我们希望将这些 100 个小文件合并成一个有序的大文件。这里就会用到优先级队列。

整体思路有点像归并排序中的合并函数。我们从这 100 个文件中,各取第一个字符串,放入堆中,然后把堆顶的那个字符串放入合并后的大文件中,并从堆中删除。

然后再从刚刚那个小文件中取下一个字符串,循环往复,直到处理完所有文档。

删除堆顶数据和往堆中插入数据的时间复杂度都是 O(logn),n 表示堆中的数据个数,这里就是 100。

  1. 高性能定时器

假设我们有一个定时器,定时器中维护了很多定时任务,每个任务都设定了一个要触发执行的时间点。定时器每过一个很小的单位时间(比如 1 秒),就扫描一遍任务,看是否有任务到达设定的执行时间。如果到达了,就拿出来执行。

但是,这样每过 1 秒就扫描一遍任务列表的做法比较低效,主要原因有两点:第一,任务的约定执行时间离当前时间可能还有很久,这样前面很多次扫描其实都是徒劳的;第二,每次都要扫描整个任务列表,如果任务列表很大的话,势必会比较耗时。

针对这些问题,我们就可以用优先级队列来解决。我们按照任务设定的执行时间,将这些任务存储在优先级队列中,队列首部(也就是小顶堆的堆顶)存储的是最先执行的任务。

这样,定时器就不需要每隔 1 秒就扫描一遍任务列表了。它拿队首任务的执行时间点,与当前时间点相减,得到一个时间间隔 T。

这个时间间隔 T 就是,从当前时间开始,需要等待多久,才会有第一个任务需要被执行。这样,定时器就可以设定在 T 秒之后,再来执行任务。从当前时间点到(T-1)秒这段时间里,定时器都不需要做任何事情。

当 T 秒时间过去之后,定时器取优先级队列中队首的任务执行。然后再计算新的队首任务的执行时间点与当前时间点的差值,把这个值作为定时器执行下一个任务需要等待的时间。

这样,定时器既不用间隔 1 秒就轮询一次,也不用遍历整个任务列表,性能也就提高了。

  1. 利用堆求中位数 将数据平均拆成两个部分,维护两个堆,一个大顶堆,一个小顶堆。大顶堆中存储前半部分数据,小顶堆中存储后半部分数据,且小顶堆中的数据都大于大顶堆中的数据。

如果是动态数据,如果新加入的数据小于等于大顶堆的堆顶元素,我们就将这个新数据插入到大顶堆;如果新加入的数据大于等于小顶堆的堆顶元素,我们就将这个新数据插入到小顶堆。

然后可以交换堆的数据来达到最终的平衡。

同样的,除了中位数,还可以求90分位数据、99分位数据(假设当前总数据的个数是 n,大顶堆中保存 n99% 个数据,小顶堆中保存 n1% 个数据。大顶堆堆顶的数据就是我们要找的 99% 响应时间。),也就是按照拆分堆的形式来实现。

三、微博热搜是怎么实现的?

假设现在我们有一个包含 10 亿个搜索关键词的日志文件,如何能快速获取到热门榜 Top 10 的搜索关键词呢?

处理这个问题,有很多高级的解决方法,比如使用 MapReduce 等。但是,如果我们将处理的场景限定为单机,可以使用的内存为 1GB。那这个问题该如何解决呢?

因为用户搜索的关键词,有很多可能都是重复的,所以我们首先要统计每个搜索关键词出现的频率。我们可以通过散列表、平衡二叉查找树或者其他一些支持快速查找、插入的数据结构,来记录关键词及其出现的次数。

假设我们选用散列表。我们就顺序扫描这 10 亿个搜索关键词。当扫描到某个关键词时,我们去散列表中查询。如果存在,我们就将对应的次数加一;如果不存在,我们就将它插入到散列表,并记录次数为 1。以此类推,等遍历完这 10 亿个搜索关键词之后,散列表中就存储了不重复的搜索关键词以及出现的次数。

然后,我们再根据前面讲的用堆求 Top K 的方法,建立一个大小为 10 的小顶堆,遍历散列表,依次取出每个搜索关键词及对应出现的次数,然后与堆顶的搜索关键词对比。如果出现次数比堆顶搜索关键词的次数多,那就删除堆顶的关键词,将这个出现次数更多的关键词加入到堆中。

以此类推,当遍历完整个散列表中的搜索关键词之后,堆中的搜索关键词就是出现次数最多的 Top 10 搜索关键词了。

不知道你发现了没有,上面的解决思路其实存在漏洞。10 亿的关键词还是很多的。我们假设 10 亿条搜索关键词中不重复的有 1 亿条,如果每个搜索关键词的平均长度是 50 个字节,那存储 1 亿个关键词起码需要 5GB 的内存空间,而散列表因为要避免频繁冲突,不会选择太大的装载因子,所以消耗的内存空间就更多了。而我们的机器只有 1GB 的可用内存空间,所以我们无法一次性将所有的搜索关键词加入到内存中。这个时候该怎么办呢?

我们在哈希算法那一节讲过,相同数据经过哈希算法得到的哈希值是一样的。我们可以哈希算法的这个特点,将 10 亿条搜索关键词先通过哈希算法分片到 10 个文件中。

具体可以这样做:我们创建 10 个空文件 00,01,02,……,09。我们遍历这 10 亿个关键词,并且通过某个哈希算法对其求哈希值,然后哈希值同 10 取模,得到的结果就是这个搜索关键词应该被分到的文件编号。

对这 10 亿个关键词分片之后,每个文件都只有 1 亿的关键词,去除掉重复的,可能就只有 1000 万个,每个关键词平均 50 个字节,所以总的大小就是 500MB。1GB 的内存完全可以放得下。

我们针对每个包含 1 亿条搜索关键词的文件,利用散列表和堆,分别求出 Top 10,然后把这个 10 个 Top 10 放在一块,然后取这 100 个关键词中,出现次数最多的 10 个关键词,这就是这 10 亿数据中的 Top 10 最频繁的搜索关键词了。

REF

https://baijiahao.baidu.com/s?id=1619076110708884185&wfr=spider&for=pc
https://cloud.tencent.com/developer/article/1456823 百度、微博的大数据算法Top10热搜怎么实现?