性能超前,详解腾讯云新一代Redis缓存数据库

背景

当前内存数据库发展迅速,用户对于存储系统的要求也越来越高,为了满足各类业务场景的需要,腾讯云设计了新一代的内存数据库,不但保留了原来系统的高性能,高可用等特性,同时还兼容了当前流行的Redis原生协议及使用方式。我们试图在解决原生方案短板的基础上,不断创新,使得新系统同时具备易懂、易用、易维护、高可靠、低成本等特点。主要体现在以下几个方面:

1.沿用了上一代自研系统使用共享内存的数据存储方案,避免Redis采用AOF机制,恢复时间过久的问题,极大的降低了在升级、进程异常等场景产生的影响。同时,使用全新的快照与流水机制,解决了Fork机制造成的内存预留问题

2. 在存储引擎方面,对于自研及开源方案进行重新分析整理,进行了再次创新,不但使用多规格Block灵活组合的存储方式,内部数据结构同样采用动态页管理,对比原生引擎,极大的提高了内存使用率的同时,也降低了运行过程中产生内存碎片的机率

3. 单进程多线程的模型让运维部署更加简便,同时精简模块数量,让请求路径更短

4.更加精细化的数据管理,实现快速的过期淘汰及精确的LRU特性

5.实现了强一致特性,满足了金融等业务对于数据一致性的强需求

6. 集群版模式中,支持了多数据库的场景,降低用户由主从版迁移至集群版的使用门槛

7.存储节点可直接转发用户请求,降低后台数据变更对于客户端的依赖,原生主从版客户端可直接访问集群版,无需修改代码

8.我们正在兼容更多的原生数据库协议,让更多的用户可以无缝切换,体验更多的新特性

技术架构优化历程

在架构方面我们将当前比较流行的两层(不包含客户端)结构简化成了单层,如下图所示。

图1 架构图

图中的Master为集群的管理节点,每组Master管理一个地域的若干集群。

Cache则是实际的数据存储节点。架构中不再显式设置接入层,而是通过Cache转发用户请求,这样做的好处:

单纯的存储或接入模块,由于对不同资源类型(CPU、网卡、内存等)需求的倾斜,无法很好的提高当前高配机型的设备利用率。也基于这个原因,理论上合并后的单层结构能更好的利用硬件资源,节约成本减少模块数量可以减少大量运维操作,便于运维同学部署及规划资源等路由更接近数据,因此在某台Cache上进行数据迁移动作时,可以更加实时的对用户请求做出应对(转发至最新的目标),减少变更对用户请求的影响

针对一些对于接入层有强需求的场景,比如,某业务的客户端链接数极多,我们也有针对性的做了优化。Cache可退化为纯接入机使用,这样可以方便的扩展为两层结构,统一使用一套代码,无需单独维护。

数据分布方面,采用了全部打散的方式,即在任意一台Cache上既有主数据也有(其他业务)备份数据,完全以Shard为粒度(物理内存单元)进行管理,如下图所示。

图2 Shard分布

每台Cache的内存被划分为若干Shard,无论是主从版还是集群版,用户的主或备数据可能落到任意Cache,分配策略支持跨机架、跨机房等。这样做的目的有:

不再有单纯的热备设备,减少低负载设备比例,充分利用整个集群的网卡、CPU等资源当一个或若干节点异常时,利用整个集群的能力进行容错(切换流量)与恢复(在不同节点重建备份),避免雪球效应在分配时,将考虑现有设备主备Shard比例及负载,优化装箱算法,可是集群资源更加均衡

由于CKV+兼容Redis协议及各种使用场景,因此也区分了主从版与集群版。对于集群版来说,经过对比,数据哈希仍然采用了Pre-sharding的方式,如下图所示。

图3数据哈希

对于单个Shard来说,最大可管理内存为8T,由于目前设备限制,实际最大可支持512G,因此集群版支持的容量范围为 [1G,512G] * 16384 = [16T,8P]。当然在实际应用中,还需考虑系统内部预留资源等因素,且Shard大小及Slot对应关系的规划也要视物理资源情况而定。

内存引擎设计,确定CKV+引擎

内存管理是内存数据库系统中非常重要的一环,在CKV+系统的设计阶段,对于引擎也是进行了大量的讨论与调研,根据我们的经验,同时吸纳了多种主流内存管理体系的优点,确定了当前CKV+的引擎方案。主要特点归纳如下:

使用共享内存,方便升级或进程异常时快速恢复基于共享内存实现了红黑树算法,在保证性能的前提下,兼容Redis中的Hash、Set、ZSet数据类型使用多规格Block作为(最小的)数据存储单位,更加灵活同时内存空隙更小使用经典的Page管理模式,优化了动态分配策略,提高了Page回收几率,降低内存碎片率用户数据所依附的内部数据结构同样基于Page进行动态分配,减少内部预留空间的浪费

图4 内存引擎

内存引擎的一个重要指标就是内存使用率,我们与原生Redis存储进行了对比测试。

测试方法:使用同样的随机数据,分别写入Redis及CKV+的1G实例,对比实际存储数据量的多少。

样本大小:key [10,30],Value [20,100]

图5 使用率对比

测试结果显示,在简单String类型的场景下,两者存储量近似,但在稍复杂的结构中,CKV+则可以存储更多的用户数据。

大胆尝试,采用单进程多线程模型

对于内存数据库来说,高性能仍然是大前提,而开发过程中使用的线程模型及框架对于这个层面影响较大。因此在设计初始,我们对于这部分也做了大胆尝试。

首先,我们使用了单进程多线程的模式,而非大多开源系统的单进程单线程的路数,一方面可以更好的利用整机资源,另一方面也能降低运维门槛。对于多线程来说,需要解决的主要问题有如下几点:

若干线程共同管理内存则势必需要引入锁,而高配机型核数多、线程多,加锁可能带来毛刺单个进程需要管理多个业务数据,特别是主从版,每块内存Shard容量较大,难免有比较庞大的kv数据,同时主从版支持部分耗时操作,需要尽量减少实例间的相互影响线程间通信或共享数据的代价要小,比如同步路由信息等同时要考虑诸如线程上下文切换、CPU缓存命中率、IO等因素

在进行了一系列的调研工作后,最终确定线程模型为:每个物理核启动一个线程,管理若干内存Shard,如下图所示。

图6 线程模型

使用这种模式的主要考虑:

具体内存的操作仅由某一个CPU处理,避免加锁,某个Shard出现热点时,对其他线程管理的实例影响较小在管理实例数量不多的情况下,空闲CPU可以处理网络及磁盘IO,以及请求的编解码等工作,提高整机资源利用率线程间不存在依赖或竞争关系,避免不必要的损耗 性能测试

性能应该是大家比较关注的部分,我们针对Redis的String与ZSet两种数据结构进行了性能测试,结果如下。

注:

"单实例"表示一台Cache仅管理1个Shard,"N实例"则表示同时管理N个Shard所有测试均使用2400个客户端对整台设备进行压测测试不涉及消息转发,即客户端直接请求数据所在设备测试样本分别使用10Byte与100Byte的数据本次测试并未启用DPDK,后续会进行补充

图7 STRING类型读写性能对比

图8 ZSET类型读写性能对比

结语

腾讯云新一代内存数据库不但全面兼容了Redis的数据结构及使用方法,同时解决了原生方案在备份、容灾等方面的不足。在性能方面,我们并没有满足于现状,后续还将更细致的优化逻辑流程,并引入DPDK等特性,进一步提升系统性能。成本也是我们关注的重点,当前的系统架构与线程模型能更好的适应不断提升的硬件设备性能,提高硬件资源的利用率,同时,我们也将引进冷热数据分离等技术,在保证性能的前提下,更好的为用户节省成本。

作者 : carloszhao,2010年加入腾讯,前后参与过分布式计算、存储等多个项目的设计与开发,目前在腾讯TEG-基础架构部,负责内存数据库的研发工作。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏CSDN技术头条

架构师于小波:魅族实时消息推送架构

【编者按】此文是根据魅族架构师于小波在msup和魅族联合举办的#魅族技术开放日#的演讲中的分享内容整理而成,于小波分享了魅族实时消息推送架构的其中遇到的坑和一些...

3267
来自专栏JAVA高级架构

多研究些架构,少谈些框架(3)-- 微服务和事件驱动

接上篇,我们采用了领域驱动的开发方式,使用了充血模型,享受了他的好处,但是也不得不面对他带来的弊端。这个弊端在分布式的微服务架构下面又被放大。 事务一致性 事务...

3234
来自专栏美团技术团队

【沙龙干货】RDS平台介绍

今天我就给大家讲一下我们这边做的数据库运维的自动化平台,他是怎么样子的。首先我会给大家简单介绍一下我们做平台的背景,以及平台的一些技术架构,以及针对我们DBA和...

5004
来自专栏Java技术

大话程序猿眼里的高并发!

高并发是指在同一个时间点,有很多用户同时的访问URL地址,比如:淘宝的双11、双12、京东618,就会产生高并发。如贴吧的爆吧,就是恶意的高并发请求,也就是DD...

961
来自专栏Web 开发

联想一键恢复7.0工程师版

我的Y450,先用分区软件分好区,C盘30G(30726MB)D盘100G(102407MB)E盘100G(102407MB)F盘53G,剩下刚好15G未分配空...

903
来自专栏Golang语言社区

Go 语言构建高并发分布式系统实践

你知道互联网最抢手的技术人才有哪些吗?最新互联网职场生态报告显示,最抢手的十大互联网技术人才排名中Go语言开发人员位居第三,从中不难见得,Go语言的渗透率越来越...

6005
来自专栏程序人生

再谈 API 的撰写 - 架构

在 再谈 API 的撰写 - 总览 里我们谈到了做一个 API 系统的基本思路和一些组件的选型,今天谈谈架构。 部署 首先要考虑的架构是部署的架构。部署的方案往...

4337
来自专栏编程心路

GitHub学习文档-1

首先 GitHub 是一个平台级的软件,在 PC端,网页端,手机端都有相应的应用,下面都是根据 GitHub 的网页端介绍的。GitHub 可以看做是一个面向开...

1226
来自专栏CSDN技术头条

Autodesk基于Mesos的通用事件系统架构

【编者按】本文由Autodesk Cloud软件架构师Olivier Paugam撰写,解释了如何集合Mesos、Kafka、RabbitMQ、Akka、Spl...

2065
来自专栏开发与安全

建议程序员都读一读的31篇论文系列笔记(1~2)

序:前几日网上偶然看到”程序员必读论文系列“,顺便搜了一下,发现有多个版本共31篇,不过看起来都不错,故准备花时间都读一下,可以拓宽下视野。来源论文题目主要参考...

2320

扫码关注云+社区