玩转GaussDB(for Cassandra)看这篇就够了(玩转那座韩城)
136
2022-07-24
背景
GaussDB(for Redis)(下文简称高斯Redis),是华为自研的强一致、持久化NoSQL数据库,兼容Redis5.0协议。在互联网时代,我们日常生活充斥着Feed流,微信朋友圈、微博、抖音以及头条等等都在使用Feed流,将我们关注的好友或感兴趣的内容及时推送给我们,使我们沉沦其中无法自拔,带来商业价值的提升。接下来将和大家一起探讨常见的Feed流系统包含的概念、架构和挑战以及如何使用高斯Redis设计一个Feed流系统。
概念
Feed流系统从形式上是Feed生成者将生产的Feed经过存储分发系统传递给Feed消费者,最终以某种展现形式。
1、Feed:单次推送的内容。 一条微博就是一个Feed。
2、Feed流:由连续的Feed组成的信息流。
3、展现形式:展示形式目前主要有Timeline和Rank。比如微博以Timeline展示。头条客户端主要以推荐Rank来进行展示。
4、Feed生产者:对于微博就是每个用户,针对头条就是推荐算法。
5、Feed消费者:接收Feed通知的主体。
6、同步存储系统:这部分一般又可以分为三部分(具体实现会略有差异)。
6-1 内容存储模块:这部分关心Feed原始内容如何存储。如你发的一条微博。
6-2 关联关系存储模块:对于微博存储的是用户的关注人和被关注人,对于头条存储的是人群(根据用户画像对所有用户进行分类)
6-3 信箱模块:一般又可叫做消息传递模块,Feed消息存储到信箱,才能最终形成Feed流。
架构设计
Feed生产者创作一条内容后发到Server端,Server端先将消息内容存储到消息存储模块,接着根据信箱模块的设计查询关系存储库将通知信息写入信箱模块, Feed消费者通过查询信箱获取及时消息。
消息存储模块:Feed内容一般都是半结构化数据,数据量大,需要持久化内容,逻辑上就是一个KV系统,ID到内容的映射关系。
关系存储模块:关联关系会发生新增和删除,是一个变长的集合,需要能够支持快速的增删查动作,一般不需要支持join等复杂操作。因此NoSQL数据库比较适合这类数据的存储。
信箱模块:说到信箱模块一般大家都会讨论是采用推模式、拉模式或推拉模式结合方式。在PB级数据库GaussDB(for Redis)揭秘第五期:高斯 Redis 在IM场景中的应用 也有过讨论。
究竟选用哪种模式,看具体业务场景和要求。
很多业务在具体实现的时候,会先将消息写入消息队列,一方面可以起到流量削峰的作用,另一方面可以实现一些特定的推送优化逻辑,如判断为垃圾广告或者敏感词不进行推送。
技术挑战
我们首先从微信朋友圈公布的数据来感受一下。在2021年1月19日,在微信公开课Pro上微信创始人张小龙披露微信最新数据:微信每天有7.8亿用户进入朋友圈,1.2亿用户发表朋友圈。平均每人打开浏览十几次,每天100亿次浏览量。若我们想实现类似的Feed流系统会有什么挑战。从存储量上来看,若用户平均每天发送3次朋友圈,每条内容1kB,一年大约1000亿条记录,存储容量接近100TB。从访问请求次数来看,每天写入和读取OPS峰值至少百万级别,用户写入和读取延迟都要有实时性,响应时间至少都要在秒级内,否则用户分分钟关闭APP。因此我们需要一个持久化、海量存储、高吞吐、易扩展、低延迟、低存储成本的分布式存储系统。
高斯Redis的优势
高斯Redis简介
Feed流场景如何利用高斯Redis优势
针对Feed流场景,可以按照如下方式使用高斯Redis:
1、消息内容存储利用高斯Redis的KV结构即可实现,高斯Redis采用存储计算分离架构,可以轻松支撑海量数据存储及低延迟访问延迟。
2、关联关系存储高斯Redis集合结构或字典结构可以轻松实现关联关系的增删改查。
3、信箱存储信箱从实现上就是一个队列,支持从指定位置消费的能力。高斯Redis的Stream结构可以实现队列能力,轻松实现Feed流消息读取。
高斯Redis Feed流实践
以上实现了一个简单的微博系统,真实系统会比这个复杂,会涉及业务场景特定处理逻辑。用高斯Redis作为Feed流存储底座是比较理想的技术选型。
总结
高斯Redis具有持久化、海量存储、高吞吐、易扩展、低延迟、低存储成本等优点, 作为Feed流存储底座非常合适,其优异的读写性能和高级特性将会极大简化应用开发。同时,高斯Redis在开源Redis基础之上,较好平衡了性能和成本,能够广泛应用在智慧医疗、流量削峰、计数器等领域。
结束
参考资料
2、《GaussDB(for Redis)与自建开源Redis的成本对比》
6、《feed流拉取,读扩散,究竟是啥?》
7、《朋友圈微博feed流,推拉实践》
发表评论
暂时没有评论,来抢沙发吧~