新浪微博应对日访问量百亿级的缓存架构设计( 二 ) _新浪微博

文章插图

实际上微博是一个广场型的业务，比如突发事件，某明星找个女朋友，瞬间流量就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进行压缩。
2、集合类数据

文章插图

刚才讲到简单的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大概要十几分钟以上，现在是毫秒级升级。
对于AOF，我们采用滚动的AOF，每个AOF是带一个ID的，达到一定的量再滚动到下一个AOF里去。对RDB落地的时候，我们会记录构建这个RDB时，AOF文件以及它所在的位置，通过新的RDB、AOF扩展模式，实现全增量复制。
3、其他数据类型-计数

文章插图

接下来还有一些其他的数据类型，比如一个计数，实际上计数在每个互联网公司都可能会遇到，对一些中小型的业务来说，实际上MC和Redis足够用的，但在微博里计数出现了一些特点：单条Key有多条计数，比如一条微博，有转发数、评论数，还有点赞；一个用户有粉丝数、关注数等各种各样的数字。因为是计数，它的Value size是比较小的，根据它的各种业务场景，大概就是2-8个字节，一般4个字节为多，然后每日新增的微博大概十亿条记录，总记录就更可观了，然后一次请求，可能几百条计数要返回去。