微博每日数十亿级业务下的计数器如何扩展Redis?
在Feed系统中,有简单数据类型的缓存,有集合类数据的。还有一些个性业务的缓存。比如大量的计数器场景,存在性判断场景等。微博解决存在性判断业务的缓存层叫EXISTENCE 缓存层,解决计算器场景的缓存叫COUNTER缓存。
EXISTENCE 缓存层主要用于缓存各种存在性判断的业务,诸如是否已赞(liked)、是否已阅读(readed)这类需求。
Feed系统内部有大量的计数场景,如用户维度有关注数、粉丝数、feed发表数,feed维度有转发数、评论数、赞数以及阅读数等。前面提到,按照传统Redis、Memcached计数缓存方案,单单存每日新增的十亿级的计数,就需要新占用百G级的内存,成本开销巨大。因此微博开发了计数服务组件CounterService。下面以计数场景来管中窥豹。
提出问题
对于计数业务,经典的构建模型有两种:1 db+