今天是微博技术解密系列的第二期，我们来聊聊微博存储的使用经验。上一期“微博技术解密”我讲到微博主要使用了两大类存储：一类是数据库，主要以 MySQL 为主；一类是缓存，主要以 Memcached 和 Redis 为主。
今天我来分享一下微博在使用数据库和缓存方面的经验，也欢迎你给我留言一起切磋讨论。
MySQL上一期我讲到微博 Feed 的存储使用了两层的结构，为了减少对 MySQL 数据库的访问压力，在前面部署了 Memcached 缓存，挡住了 99% 的访问压力，只有 1% 的请求会访问数据库。然而对于微博业务来说，这 1% 的请求也有几万 QPS，对于单机只能扛几千 QPS 的 MySQL 数据库来说还是太大了。为此我们又对数据库端口进行了拆分，你可以看下面的示意图，每个用户的 UID 是唯一的，不同 UID 的用户按照一定的 Hash 规则访问不同的端口，这样的话单个数据库端口的访问量就会变成原来的 1/8。除此之外，考虑到微博的读请求量要远大于写请求量，所以有必要对数据库的读写请求进行分离，写请求访问 Master，读请求访问 Slave，这样的话 Master 只需要一套，Slave 根据访问量的需要可以有多套，也就是“一主多从”的架构。最后考虑到灾备的需要，还会在异地部署一套冷备的灾备数据库，平时不对外提供线上服务，每天对所有最新的数据进行备份，以防线上数据库发生同时宕机的情况。
在 MySQL 数据库前面，还使用了 Memcached 作为缓存来承担几百万 QPS 的数据请求，产生的带宽问题是最大挑战。为此微博采用了下图所示的多层缓存结构，即 L1-Master-Slave，它们的作用各不相同。
L1 主要起到分担缓存带宽压力的作用，并且如果有需要可以无限进行横向扩展，任何一次数据请求，都随机请求其中一组 L1 缓存，这样的话，假如一共 10 组 L1，数据请求量是 200 万 QPS，那么每一组 L1 缓存的请求量就是 1/10，也就是 20 万 QPS；同时每一组缓存又包含了 4 台机器，按照用户 UID 进行 Hash，每一台机器只存储其中一部分数据，这样的话每一台机器的访问量就只有 1/4 了。
Master 主要起到防止访问穿透到数据库的作用，所以一般内存大小要比 L1 大得多，以存储尽可能多的数据。当 L1 缓存没有命中时，不能直接穿透到数据库，而是先访问 Master。
Slave 主要起到高可用的目的，以防止 Master 的缓存宕机时，从 L1 穿透访问的数据直接请求数据库，起到“兜底”的作用。
微博的存储除了大量使用 MySQL 和 Memcached 以外，还有一种存储也被广泛使用，那就是 Redis。并且基于微博自身的业务特点，我们对原生的 Redis 进行了改造，因此诞生了两类主要的 Redis 存储组件：CounterService 和 Phantom。
1. CounterService
CounterService 的主要应用场景就是计数器，比如微博的转发、评论、赞的计数。早期微博曾采用了 Redis 来存储微博的转发、评论、赞计数，但随着微博的数据量越来越大，发现 Redis 内存的有效负荷还是比较低的，它一条 KV 大概需要至少 65 个字节，但实际上一条微博的计数 Key 需要 8 个字节，Value 大概 4 个字节，实际上有效的只有 12 个字节，其余四十多个字节都是被浪费的。这还只是单个 KV，如果一条微博有多个计数的情况下，它的浪费就更多了，比如转评赞三个计数，一个 Key 是 long 结构，占用 8 个字节，每个计数是 int 结构，占用 4 个字节，三个计数大概需要 20 个字节就够了；而使用 Redis 的话，需要将近 200 个字节。正因为如此，我们研发了 CounterService，相比 Redis 来说它的内存使用量减少到原来的 1/15～1/5。而且还进行了冷热数据分离，热数据放到内存里，冷数据放到磁盘上，并使用 LRU，如果冷数据重新变热，就重新放到内存中。
你可以看下面的示意图，CounterService 的存储结构上面是内存下面是 SSD，预先把内存分成 N 个 Table，每个 Table 根据微博 ID 的指针序列，划出一定范围。任何一个微博 ID 过来先找到它所在的 Table，如果有的话，直接对它进行增减；如果没有，就新增加一个 Key。有新的微博 ID 过来，发现内存不够的时候，就会把最小的 Table dump 到 SSD 里面去，留着新的位置放在最上面供新的微博 ID 来使用。如果某一条微博特别热，转发、评论或者赞计数超过了 4 个字节，计数变得很大该怎么处理呢？对于超过限制的，我们把它放在 Aux Dict 进行存放，对于落在 SSD 里面的 Table，我们有专门的 Index 进行访问，通过 RDB 方式进行复制。
