物流大超市

标题: 解析1性能超前，详解讯云新一代Redis缓存数据库 [打印本页]

作者: kaixun 时间: 2023-2-23 23:12
标题: 解析1性能超前，详解讯云新一代Redis缓存数据库

背景

织梦网站的最新消息可以到我们平台网站了解一下，也可以咨询客服人员进行详细的解答！

当前内存数据库发展迅速，用户对于存储系统的要求也越来越高，为了满足各类业务场景的需要，讯云设计了新一代的内存数据库，不但保留了原来系统的高性能，高可用等特性，同时还兼容了当前流行的R原生协议及使用方式。我们试图在解决原生方案短板的基础上，不断创新，使得新系统同时具备易懂、易用、易维护、高可靠、低成本等特点。主要体现在以下几个方面：
1沿用了上一代自研系统使用共享内存的数据存储方案，避免R采用AOF机制，恢复时间过久的问题，极大的降低了在升级、进程异常等场景产生的影响。同时，使用全新的照与流水机制，解决了F机制造成的内存预留问题
2 在存储引擎方面，对于自研及开源方案进行重新分析整理，进行了再次创新，不但使用多规格B灵活组合的存储方式，内部数据结构同样采用动态页管理，对比原生引擎，极大的提高了内存使用率的同时，也降低了运行过程中产生内存碎片的机率
3 单进程多线程的模型让运维部署更加简便，同时精简模块数量，让请求路径更短
4更加精细化的数据管理，现速的过期淘汰及精确的LRU特性
5现了强一致特性，满足了金融等业务对于数据一致性的强需求
6 集群版模式中，支持了多数据库的场景，降低用户由主从版迁移至集群版的使用门槛
7存储节点可直接转发用户请求，降低后台数据变更对于客户端的依赖，原生主从版客户端可直接访问集群版，需修改代码
8我们正在兼容更多的原生数据库协议，让更多的用户可以缝切换，体验更多的新特性
技术架构化历程

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

图1 架构图
图中的M为集群的管理节点，每组M管理一个地域的若干集群。
C则是际的数据存储节点。架构中不再显式设置接入层，而是通过C转发用户请求，这样做的好处：
单纯的存储或接入模块，由于对不同资源类型(CPU、卡、内存等)需求的倾斜，法很好的提高当前高配机型的设备利用率。也基于这个原因，理论上合并后的单层结构能更好的利用硬件资源，节约成本
减少模块数量可以减少大量运维操作，便于运维同学部署及规划资源等
路由更接近数据，因此在某台C上进行数据迁移动作时，可以更加时的对用户请求做出应对(转发至比较新的目标)，减少变更对用户请求的影响
针对一些对于接入层有强需求的场景，比如，某业务的客户端链接数极多，我们也有针对性的做了化。C可退化为纯接入机使用，这样可以方便的扩展为两层结构，统一使用一套代码，需单独维护。
数据分布方面，采用了全部打散的方式，即在任意一台C上既有主数据也有(其他业务)备份数据，完全以S为粒度(物理内存单元)进行管理，如下图所示。

图2 S分布
每台C的内存被划分为若干S，论是主从版还是集群版，用户的主或备数据可能落到任意C，分配策略支持跨机架、跨机房等。这样做的目的有：
不再有单纯的热备设备，减少低负载设备比例，充分利用整个集群的卡、CPU等资源
当一个或若干节点异常时，利用整个集群的能力进行容错(切换流量)与恢复(在不同节点重建备份)，避免雪球效应
在分配时，将考虑现有设备主备S比例及负载，化装箱算法，可是集群资源更加均衡
由于CKV+兼容R协议及各种使用场景，因此也区分了主从版与集群版。对于集群版来说，经过对比，数据哈希仍然采用了P-的方式，如下图所示。

图3 数据哈希
对于单个S来说，比较大可管理内存为8T，由于目前设备限制，际比较大可支持512G，因此集群版支持的容量范围为 [1G，512G] * 16384 = [16T，8P]。当然在际应用中，还需考虑系统内部预留资源等因素，且S大小及S对应关系的规划也要视物理资源情况而定。
内存引擎设计，确定CKV+引擎

内存管理是内存数据库系统中非常重要的一环，在CKV+系统的设计阶段，对于引擎也是进行了大量的讨论与调研，根据我们的经验，同时吸纳了多种主流内存管理体系的点，确定了当前CKV+的引擎方案。主要特点归纳如下：
使用共享内存，方便升级或进程异常时速恢复
基于共享内存现了红黑树算法，在保证性能的前提下，兼容R中的H、S、ZS数据类型
使用多规格B作为(比较小的)数据存储单位，更加灵活同时内存空隙更小
使用经典的P管理模式，化了动态分配策略，提高了P回收几率，降低内存碎片率
用户数据所依附的内部数据结构同样基于P进行动态分配，减少内部预留空间的浪费

图4 内存引擎
内存引擎的一个重要指标就是内存使用率，我们与原生R存储进行了对比测试。
测试方法：使用同样的随机数据，分别写入R及CKV+的1G例，对比际存储数据量的多少。
样本大小： [10，30]，V [20，100]

图5 使用率对比
测试结果显示，在简单S类型的场景下，两者存储量近似，但在稍复杂的结构中，CKV+则可以存储更多的用户数据。
大胆尝试，采用单进程多线程模型

对于内存数据库来说，高性能仍然是大前提，而开发过程中使用的线程模型及框架对于这个层面影响较大。因此在设计初始，我们对于这部分也做了大胆尝试。
首先，我们使用了单进程多线程的模式，而非大多开源系统的单进程单线程的路数，一方面可以更好的利用整机资源，另一方面也能降低运维门槛。对于多线程来说，需要解决的主要问题有如下几点：
若干线程共同管理内存则势必需要引入锁，而高配机型核数多、线程多，加锁可能带来毛刺
单个进程需要管理多个业务数据，特别是主从版，每块内存S容量较大，难免有比较庞大的数据，同时主从版支持部分耗时操作，需要尽量减少例间的相互影响
线程间通信或共享数据的代价要小，比如同步路由信息等
同时要考虑诸如线程上下文切换、CPU缓存命中率、IO等因素
在进行了一系列的调研工作后，比较终确定线程模型为：每个物理核启动一个线程，管理若干内存S，如下图所示。

图6 线程模型
使用这种模式的主要考虑：
具体内存的操作仅由某一个CPU处理，避免加锁，某个S出现热点时，对其他线程管理的例影响较小
在管理例数量不多的情况下，空闲CPU可以处理络及磁盘IO，以及请求的成都建设编解码等工作，提高整机资源利用率
线程间不存在依赖或竞争关系，避免不必要的损耗
性能测试

性能应该是大家比较关注的部分，我们针对R的S与ZS两种数据结构进行了性能测试，结果如下。
注：
单例表示一台C仅管理 1 个S，N例则表示同时管理N个S
所有测试均使用 2400 个客户端对整台设备进行压测
测试不涉及消息转发，即客户端直接请求数据所在设备
测试样本分别使用10B与100B的数据
本次测试并未启用DPDK，后续会进行补充

图7 STRING类型读写性能对比

图8 ZSET类型读写性能对比
结语

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

欢迎光临物流大超市 (https://www.9999956.com/bbs/)