微博每日数十亿级业务下的计数器如何扩展Redis？-InfoQ

在 Feed 系统中，有简单数据类型的缓存，有集合类数据的。还有一些个性业务的缓存。比如大量的计数器场景，存在性判断场景等。微博解决存在性判断业务的缓存层叫 EXISTENCE 缓存层，解决计算器场景的缓存叫 COUNTER 缓存。

EXISTENCE 缓存层主要用于缓存各种存在性判断的业务，诸如是否已赞（liked）、是否已阅读（readed）这类需求。

Feed 系统内部有大量的计数场景，如用户维度有关注数、粉丝数、feed 发表数，feed 维度有转发数、评论数、赞数以及阅读数等。前面提到，按照传统 Redis、Memcached 计数缓存方案，单单存每日新增的十亿级的计数，就需要新占用百 G 级的内存，成本开销巨大。因此微博开发了计数服务组件 CounterService。下面以计数场景来管中窥豹。

提出问题

对于计数业务，经典的构建模型有两种：1 db+cache 模式，全量计数存在 db，热数据通过 cache 加速；2 全量存在 Redis 中。方案 1 通用成熟，但对于一致性要求较高的计数服务，以及在海量数据和高并发访问场景下，支持不够友好，运维成本和硬件成本较高，微博上线初期曾使用该方案，在 Redis 面世后很快用新方案代替。方案 2 基于 Redis 的计数接口 INCR、DECR，能很方便的实现通用的计数缓存模型，再通过 hash 分表，master-slave 部署方式，可以实现一个中小规模的计数服务。

但在面对千亿级的历史海量计数以及每天十亿级的新增计数，直接使用 Redis 的计数模型存在严重的成本和性能问题。首先 Redis 计数作为通用的全内存计数模型，内存效率不高。存储一个 key 为 8 字节（long 型 id）、value 为 4 字节的计数，Redis 至少需要耗费 65 字节。1000 亿计数需要 100G*65=6.5T 以上的内存，算上一个 master 配 3 个 slave 的开销，总共需要 26T 以上的内存，按单机内存 96G 计算，扣掉 Redis 其他内存管理开销、系统占用，需要 300-400 台机器。如果算上多机房，需要的机器数会更多。其次 Redis 计数模型的获取性能不高。一条微博至少需要 3 个计数查询，单次 feed 请求如果包含 15 条微博，仅仅微博计数就需要 45 个计数查询。

解决问题

在 Feed 系统的计数场景，单条 feed 的各种计数都有相同的 key（即微博 id），可以把这些计数存储在一起，就能节省大量的 key 的存储空间，让 1000 亿计数变成了 330 亿条记录；近一半的微博没有转、评论、赞，抛弃 db+cache 的方案，改用全量存储的方案，对于没有计数为 0 的微博不再存储，如果查不到就返回 0，这样 330 亿条记录只需要存 160 亿条记录。然后又对存储结构做了进一步优化，三个计数和 key 一起一共只需要 8+43=20 字节。总共只需要 16G20=320G，算上 1 主 3 从，总共也就只需要 1.28T，只需要 15 台左右机器即可。同时进一步通过对 CounterService 增加 SSD 扩展支持，按 table 滚动，老数据落在 ssd，新数据、热数据在内存，1.28T 的容量几乎可以用单台机器来承载（当然考虑访问性能、可用性，还是需要 hash 到多个缓存节点，并添加主从结构）。

计数器组件的架构如图 13-14，主要特性如下：

1）内存优化：通过预先分配的内存数组 Table 存储计数，并且采用 double hash 解决冲突，避免 Redis 实现中的大量指针开销。

2） Schema 支持多列:一个 feed id 对应的多个计数可以作为一条计数记录，还支持动态增减计数列，每列的计数内存使用精简到 bit；

3）冷热数据分离，根据时间维度，近期的热数据放在内存，之前的冷数据放在磁盘，降低机器成本；

4） LRU 缓存：之前的冷数据如果被频繁访问则放到 LRU 缓存进行加速；

5）异步 IO 线程访问冷数据：冷数据的加载不影响服务的整体性能。