福运通网络营销与深圳SEO优化第一品牌

专为中小企业提供网络营销服务
最新资讯

微博信息流,分享微博信息流是怎样实现的

    Time: 2020-09-09来源:福运通

专栏结束后,有不少同学留言希望我能讲一些微博基础架构的知识。所以接下来的微博技术解密系列,我将分享微博在信息流架构、存储中间件等方面的经验,希望能给你带来启发和帮助。

今天我们先来看微博信息流架构,也就是微博的 Feed 是如何构建的。首先什么是 Feed 呢?根据我的理解,Feed 是互联网 2.0 时代的产物,它与互联网 1.0 时代的产物——门户网站最大的不同之处就是 Feed 不需要用户在各个板块之间来回跳转获取信息,而是把不同的信息都聚合在一起,可以供用户源源不断地访问。这里就涉及了两个问题,一个是信息如何保存,另一个是信息如何聚合。这也是今天我要分享的主要内容,我会从存储架构的角度阐述微博 Feed 是如何存储的,然后会从业务架构的角度阐述微博 Feed 是如何聚合的。

微博 Feed 存储架构

我们知道,微博 Feed 是由关注人的微博聚合在一起组成的,所以要存储每个人发的微博,那么在设计存储架构时主要需要注意三个问题:

每秒数据写入量,也就是每秒发博量是多大。

每秒数据访问量,也就是每秒微博请求量是多大。

是否有冷热数据之分,也就是微博的请求是否有时间特点。

结合微博的业务场景,我来回答上面提出的三个问题。首先是每秒发博量,这里要考虑到极端情况,比如元旦零点,瞬间会有大量用户发博,达到数万 QPS。再来看下每秒微博请求量,同样要考虑到在热点事件时,比如“春晚”时会有大量用户访问微博,请求量也会达到数万 QPS;并且每个用户关注的不止是一个人,假设关注数的平均值是 200,那么微博数据的请求量就是几百万 QPS。除此之外,微博的访问也是有时间特点的,用户一般访问新发微博的概率要远远大于一周前发的微博,所以说微博数据也是有冷热之分的。

这三个问题共同决定了微博的存储架构应该如何设计。在讨论微博存储架构前,我们先来看看目前业界比较成熟的存储方案,主要分为下面几种。

以 MySQL 为代表的关系型数据库。主要用来存储结构比较固定的数据,因为使用的是磁盘存储,所以写入和访问能力主要取决于磁盘的读写能力。而磁盘主要分为 SAS 盘和 SSD 盘,也就是机械盘和固态盘,两者的读写能力有一定的差距,SSD 盘读写能力是 SAS 盘的 3 倍左右,不过 QPS 都在千级别。磁盘存储的特点是不易丢失数据,可以永久保存。

以 Memcached 和 Redis 为代表的内存存储。服务器的内存大小一般要远小于磁盘,在几十 GB 到几百 GB 之间,而磁盘通常都是 TB 级。内存存储的优势就是读写速度快,读写能力能到几十万 QPS,远远大于磁盘存储。但由于数据存储在内存中,如果进程挂掉或者机器重启,内存中的数据就清空了。

HBase 为代表的分布式存储。属于非关系型数据库,它的特点是数据结构不固定,因此适合非结构化的数据存储,而且由于采用了分布式存储,使用 HDFS 作为底层文件存储系统,所以可以存储海量数据,并且具备非常高的写入性能。

讲到这里,结合前面提到的微博业务场景,你觉得存储架构该如何设计呢?

根据微博的实际业务情况,用户的微博需要永久保存,也就是进行持久化存储,而且微博的数据结构是固定的,优先考虑采用关系型数据库,因此 MySQL 是一种选择。但是考虑到单台 MySQL 读能力的极限是不到一万 QPS,而微博的数据请求量是几百万 QPS,如果单纯使用 MySQL 来应对的话,需要上千台服务器,成本非常高。还有一点就是微博数据的请求是有冷热之分的,一周外的数据访问的概率要远小于一周内的数据。综合以上几点考虑,可以在 MySQL 存储的前面,再加一层缓存,比如使用 Memcached,存储最近一周内的微博,而用户的全量微博数据则持久化存储在 MySQL 中。假设用户访问一周内微博的概率是 99%,那么对缓存的请求量就是几百万 QPS,而对数据库的请求量就只有几万 QPS 了,而缓存的读写能力是几十万 QPS,相比较而言,需要的机器数要远小于只使用数据库了。

微博 Feed 业务架构

经过前面的讲解,假设我们已经使用 MySQL + Memcached 的双层存储架构解决了微博的存储问题,接下来面临的问题就是,如何将存储的关注人的微博数据聚合成一股源源不断的信息流以供用户访问。

根据我的经验,信息流聚合一般有三种架构:推模式、拉模式以及推拉结合,下面我来详细讲解这三种架构。

1. 推模式

深圳SEO:http://www.tianying888.com

关键词:微博信息流