正文
![]()
作者介绍
陈波
，新浪微博技术专家，《深入分布式缓存》作者。
注：
本文转自中生代技术订阅号（ID：freshmanTechnology），经平台授权转载。
微博日活跃用户1.6亿+，每日访问量达百亿级，面对庞大用户群的海量访问，良好的架构且不断改进的缓存体系具有非常重要的支撑作用。本文将由新浪微博技术专家陈波老师，跟大家详细讲解那些庞大的数据都是如何呈现的。
本文大纲
1、微博在运行过程中的数据挑战
2、Feed平台系统架构
3、Cache架构及演进
4、总结与展望
![]()
![]()
Feed平台系统架构总共分为五层，最上面是端层，比如web端、客户端、大家用的IOS或安卓的一些客户端，还有一些开放平台、第三方接入的一些接口；下一层是平台接入层，不同的池子，主要是为了把好的资源集中调配给重要的核心接口，这样遇到突发流量的时候，就有更好的弹性来服务，提高服务稳定性。再下面是平台服务层，主要是Feed算法、关系等等。接下来是中间层，通过各种中间介质提供一些服务。最下面一层就是存储层。
![]()
大家日常刷微博的时候，比如在主站或客户端点一下刷新，最新获得了十到十五条微博，这是怎么构建出来的呢？
刷新之后，首先会获得用户的关注关系。比如他有一千个关注，会把这一千个ID拿到，再根据这一千个UID，拿到每个用户发表的一些微博。同时会获取这个用户的Inbox，就是他收到的特殊的一些消息，比如分组的一些微博、群的微博、下面的关注关系、关注人的微博列表。
拿到这一系列微博列表之后进行集合、排序，拿到所需要的那些ID，再对这些ID去取每一条微博ID对应的微博内容。如果这些微博是转发过来的，它还有一个原微博，会进一步取原微博内容。通过原微博取用户信息，进一步根据用户的过滤词对这些微博进行过滤，过滤掉用户不想看到的微博。
根据以上步骤留下的微博，会再进一步来看，用户对这些微博有没有收藏、点赞，做一些flag设置，还会对这些微博各种计数，转发、评论、赞数进行组装，最后才把这十几条微博返回给用户的各种端。
这样看来，用户一次请求得到的十几条记录，后端服务器大概要对几百甚至几千条数据进行实时组装，再返回给用户，整个过程对Cache体系强度依赖，所以Cache架构设计优劣会直接影响到微博体系表现的好坏。
![]()
接下来我们看一下Cache架构，它主要分为六层。首先第一层是Inbox，主要是分组的一些微博，然后直接对群主的一些微博。Inbox比较少，主要是推的方式。
然后对于第二层的Outbox，每个用户都会发常规的微博，都会在它的Outbox里面去。根据存的ID数量，实际上分成多个Cache，普通的大概是200多条，如果长的大概是2000条。
第三层是一些关系，它的关注、粉丝、用户。
第四层是内容，每一条微博一些内容存在这里。
第五层就是一些存在性判断，比如某条微博我有没有赞过。之前有一些明星就说我没有点赞这条微博怎么显示我点赞了，引发了一些新闻。而这种就是记录，实际上她有在某个时候点赞过但可能忘记了。
最下面还有比较大的一层——计数，每条微博的评论、转发等计数，还有用户的关注数、粉丝数这些数据。
![]()
接下来我们着重讲一下微博的Cache架构演进过程。最开始微博上线时，我们是把它作为一个简单的KV数据类型来存储。我们主要采取哈希分片存储在MC池子里，上线几个月之后发现一些问题：有一些节点机器宕机或是其它原因，大量的请求会穿透Cache层达到DB上去，导致整个请求变慢，甚至DB僵死。
于是我们很快进行了改造，增加了一个HA层，这样即便Main层出现某些节点宕机情况或者挂掉之后，这些请求会进一步穿透到HA层，不会穿透到DB层。这样可以保证在任何情况下，整个系统命中率不会降低，系统服务稳定性有了比较大的提升。
对于这种做法，现在业界用得比较多，然后很多人说我直接用哈希，但这里面也有一些坑。比如我有一个节点，节点3宕机了，Main把它给摘掉，节点3的一些QA分给其他几个节点，这个业务量还不是很大，穿透DB，DB还可以抗住。但如果这个节点3恢复了，它又加进来之后，节点3的访问就会回来，稍后节点3因为网络原因或者机器本身的原因，它又宕机了，一些节点3的请求又会分给其他节点。这个时候就会出现问题，之前分散给其他节点写回来的数据已经没有人更新了，如果它没有被剔除掉就会出现混插数据。
![]()
实际上微博是一个广场型的业务，比如突发事件，某明星找个女朋友，瞬间流量就30%了。突发事件后，大量的请求会出现在某一些节点，会导致这些节点非常热，即便是MC也没办法满足这么大的请求量。这时MC就会变成瓶颈，导致整个系统变慢。
基于这个原因，我们引入了L1层，还是一个Main关系池，每一个L1大概是Main层的N分之一，六分之一、八分之一、十分之一这样一个内存量，根据请求量我会增加4到8个L1，这样所有请求来了之后首先会访问L1。L1命中的话就会直接访问，如果没有命中再来访问Main-HA层，这样在一些突发流量的时候，可以由L1来抗住大部分热的请求。对微博本身来说，新的数据就会越热，只要增加很少一部分内存就会抗住更大的量。
![]()
简单总结一下，通过简单KV数据类型的存储，我们实际上以MC为主的，层内HASH节点不漂移，Miss穿透到下一层去读取。通过多组L1读取性能提升，能够抗住峰值、突发流量，而且成本会大大降低。对读写策略，采取多写，读的话采用逐层穿透，如果Miss的话就进行回写。对存在里面的数据，我们最初采用Json/xml，2012年之后就直接采用Protocol Buffer格式，对一些比较大的用QuickL进行压缩。
![]()
刚才讲到简单的QA数据，那对于复杂的集合类数据怎么来处理？
比如我关注了2000人，新增一个人，就涉及到部分修改。有一种方式是把2000个ID全部拿下来进行修改，但这种对带宽、机器压力会很大。还有一些分页获取，我存了2000个，只需要取其中的第几页，比如第二页，也就是第十到第二十个，能不能不要全量把所有数据取回去。还有一些资源的联动计算，会计算到我关注的某些人里面ABC也关注了用户D。这种涉及到部分数据的修改、获取，包括计算，对MC来说实际上是不太擅长的。
各种关注关系都存在Redis里面取，通过Hash分布、储存，一组多存的方式来进行读写分离。现在Redis的内存大概有30个T，每天都有2-3万亿的请求。
![]()
在使用Redis的过程中，实际上还是遇到其他一些问题。比如从关注关系，我关注了2000个UID，有一种方式是全量存储，但微博有大量的用户，有些用户登陆得比较少，有些用户特别活跃，这样全部放在内存里成本开销是比较大的。所以我们就把Redis使用改成Cache，比如只存活跃的用户，如果你最近一段时间没有活跃，会把你从Redis里踢掉，再次有访问的时候再把你加进来。
这时存在一个问题，因为Redis工作机制是单线程模式，如果它加某一个UV，关注2000个用户，可能扩展到两万个UID，两万个UID塞回去基本上Redis就卡住了，没办法提供其他服务。所以我们扩展一种新的数据结构，两万个UID直接开了端，写的时候直接依次把它写到Redis里面去，读写的整个效率就会非常高。它的实现是一个long型的开放数组，通过Double Hash进行寻址。
![]()
我们对Redis进行了一些其他的扩展，大家可能也在网上看到过我们之前的一些分享，把数据放到公共变量里面，整个升级过程，我们测试1G的话加载要10分钟，10G大概要十几分钟以上，现在是毫秒级升级。
