百亿级日访问量的应用如何做缓存架构设计？

引言

“ 微博日活跃用户 1.6 亿+，每日访问量达百亿级，面对庞大用户群的海量访问，良好的架构且不断改进的缓存体系具有非常重要的支撑作用。

本文由新浪微博技术专家陈波老师，分为如下四个部分跟大家详细讲解那些庞大的数据都是如何呈现的：

• 微博在运行过程中的数据挑战
• Feed 平台系统架构
• Cache 架构及演进
• 总结与展望

 微博在运行过程中的数据挑战

 Feed 平台系统架构

Feed 平台系统架构总共分为五层：

• 最上面是端层，比如 Web 端、客户端、大家用的 iOS 或安卓的一些客户端，还有一些开放平台、第三方接入的一些接口。
• 下一层是平台接入层，不同的池子，主要是为了把好的资源集中调配给重要的核心接口，这样遇到突发流量的时候，就有更好的弹性来服务，提高服务稳定性。
• 再下面是平台服务层，主要是 Feed 算法、关系等等。
• 接下来是中间层，通过各种中间介质提供一些服务。
• 最下面一层就是存储层。

 Feed Timeline

大家日常刷微博的时候，比如在主站或客户端点一下刷新，最新获得了十到十五条微博，这是怎么构建出来的呢？

刷新之后，首先会获得用户的关注关系。比如他有一千个关注，会把这一千个 ID 拿到，再根据这一千个 UID，拿到每个用户发表的一些微博。

同时会获取这个用户的 Inbox，就是他收到的特殊的一些消息，比如分组的一些微博、群的微博、下面的关注关系、关注人的微博列表。

拿到这一系列微博列表之后进行集合、排序，拿到所需要的那些 ID，再对这些 ID 去取每一条微博 ID 对应的微博内容。

如果这些微博是转发过来的，它还有一个原微博，会进一步取原微博内容。通过原微博取用户信息，进一步根据用户的过滤词对这些微博进行过滤，过滤掉用户不想看到的微博。

根据以上步骤留下的微博，会再进一步来看，用户对这些微博有没有收藏、点赞，做一些 Flag 设置，还会对这些微博各种计数，转发、评论、赞数进行组装，最后才把这十几条微博返回给用户的各种端。

这样看来，用户一次请求得到的十几条记录，后端服务器大概要对几百甚至几千条数据进行实时组装，再返回给用户。

整个过程对 Cache 体系强度依赖，所以 Cache 架构设计优劣会直接影响到微博体系表现的好坏。

 Feed Cache 架构

接下来我们看一下 Cache 架构，它主要分为六层：

• 第一层是 Inbox，主要是分组的一些微博，然后直接对群主的一些微博。Inbox 比较少，主要是推的方式。
• 第二层是 Outbox，每个用户都会发常规的微博，都会到它的 Outbox 里面去。根据存的 ID 数量，实际上分成多个 Cache，普通的大概是 200 多条，如果长的大概是 2000 条。
• 第三层是一些关系，它的关注、粉丝、用户。
• 第四层是内容，每一条微博一些内容存在这里。
• 第五层就是一些存在性判断，比如某条微博我有没有赞过。之前有一些明星就说我没有点赞这条微博怎么显示我点赞了，引发了一些新闻。而这种就是记录，实际上她有在某个时候点赞过但可能忘记了。
• 最下面还有比较大的一层——计数，每条微博的评论、转发等计数，还有用户的关注数、粉丝数这些数据