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

本文涉及的产品
云数据库 Redis 版,社区版 2GB
推荐场景:
搭建游戏排行榜
简介:

在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+4*3=20字节。总共只需要16G*20=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线程访问冷数据:冷数据的加载不影响服务的整体性能。

576bb424413f5d4d273c8887f5d9ad0bcabcf159


图 13-14 基于Redis扩展后的计数器存储架构

通过上述的扩展,内存占用降为之前的5-10%以下,同时一条feed的评论/赞等多个计数、一个用户的粉丝/关注/微博等多个计数都可以一次性获取,读取性能大幅提升,基本彻底解决了计数业务的成本及性能问题。


原文发布时间为:2018-03-12

本文作者:深入分布式缓存

本文来自云栖社区合作伙伴“互联网架构师”,了解相关信息可以关注“互联网架构师”。

相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore     ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
1月前
|
NoSQL Linux PHP
php添加redis扩展 linux和windos图文详解 l
php添加redis扩展 linux和windos图文详解 l
13 0
|
10月前
|
存储 NoSQL 安全
保障安全与可扩展性:Redis安全设置与集群扩展
本篇深入探讨了Redis的安全性设置以及构建可扩展的Redis集群的方法。我们首先介绍了如何通过设置密码、禁用危险命令和限制访问来加强Redis的安全性。进一步地,我们讨论了如何进行访问控制和权限管理,以确保只有授权用户可以访问和操作Redis。
369 2
保障安全与可扩展性:Redis安全设置与集群扩展
|
1月前
|
存储 NoSQL 关系型数据库
图解 Redis String 底层数据结构 SDS 与计数器实战
图解 Redis String 底层数据结构 SDS 与计数器实战
69 0
|
1月前
|
存储 缓存 运维
Redis专题(持续更新) 03-VIP-Redis高可用集群之水平扩展
本文介绍了如何通过水平扩展来提升Redis高可用集群的性能和可用性。文章首先展示了如何启动整个集群,并使用客户端连接至特定端口的Redis实例以及查看集群状态。接着详细介绍了增加Redis实例的步骤,包括配置新的主节点和从节点,并使用命令进行节点的添加和删除操作。其中还包括了重新分片操作以及将从节点指定给主节点的过程。最后,文章以删除主节点为结束,展示了如何将数据迁移至其他节点后进行节点的删除操作。整篇文章详细介绍了Redis高可用集群的水平扩展操作,对于需要扩展Redis集群的运维人员具有一定的指导意义。
|
1月前
|
NoSQL 算法 安全
用万字长文来讲讲本地锁至分布式锁的演进和Redis实现,扩展 Redlock 红锁3
用万字长文来讲讲本地锁至分布式锁的演进和Redis实现,扩展 Redlock 红锁
116 0
|
1月前
|
存储 NoSQL Java
用万字长文来讲讲本地锁至分布式锁的演进和Redis实现,扩展 Redlock 红锁2
用万字长文来讲讲本地锁至分布式锁的演进和Redis实现,扩展 Redlock 红锁
45 1
|
1月前
|
缓存 NoSQL 关系型数据库
用万字长文来讲讲本地锁至分布式锁的演进和Redis实现,扩展 Redlock 红锁1
用万字长文来讲讲本地锁至分布式锁的演进和Redis实现,扩展 Redlock 红锁
91 1
|
7月前
|
NoSQL Redis
轻松掌握组件启动之Redis集群扩展秘籍:轻松扩容与缩容,释放高性能潜能
在这篇文章中,我们将揭示Redis集群的扩容和缩容操作,让您的Redis集群发挥最佳性能和可伸缩性。通过增加主节点和从节点,并将它们无缝添加到集群中,您将能够轻松扩展您的Redis集群以满足不断增长的需求。同时,我们还将探讨如何进行缩容操作,即删除节点,以优化集群资源的利用。无论您是初学者还是经验丰富的Redis用户,本文将为您提供一系列有用的技巧和最佳实践,帮助您更好地管理和优化Redis集群,实现更高的性能和可扩展性。
110 0
|
7月前
|
缓存 NoSQL 中间件
太卷了!京东、微博最新「Redis缓存高手心法手册」竟被开源了
众所周知,分布式架构被广泛应用于企业级应用开发中,以满足高并发、高可用、高性能、高扩展性等要求。
|
11月前
|
设计模式 缓存 NoSQL
简述 Spring Session 集成 Redis 底层实现及自定义扩展配置
简述 Spring Session 集成 Redis 底层实现及自定义扩展配置
401 0