华为云企业级Redis揭秘第12期:2021最新架构分享

高斯Redis官方博客 发表于 2021/06/29 14:23:52 2021/06/29
【摘要】 云数据库GaussDB(for Redis)作为华为云旗下企业级Redis,致力于为客户提供稳定可靠、超高并发,且能够极速弹性扩容的KV存储服务。

【最新活动】企业级Redis专场热销中!首月免费,包年仅需4折!


前言:本文根据华为云NoSQL数据库架构师余汶龙,在今年的中国系统架构师大会SACC上的演讲整理而成,内容如下。

本次分享的大纲分成如下四个部分:

  1. 什么是GaussDB(for Redis)
  2. 为什么选择存算分离
  3. 设计与实现
  4. 竞争力总结

1.  什么是GaussDB(for Redis)

1.1 开源Redis有哪些缺点?

要回答什么是GaussDB(for Redis)(下文简称高斯Redis)的问题,首先要从背景讲起。开源Redis是个非常好的KV缓存,但随着各种业务的蓬勃发展,数据规模、吞吐规模、业务复杂度的不断上升,开源Redis暴露出诸多问题:

    1. AOF膨胀问题

    开源Redis的定位是缓存,但为了满足业务的宕机数据快速恢复,增加了AOF日志来实现一定的持久化功能。可惜在Redis的设计里,并没有一个转储文件机制来消耗AOF,而是通过AOF重写,来不断的去重合并旧日志。而该重写机制需要一次fork调用,该调用会带来内存翻倍、性能阻塞等问题。

     

    2. 快照备份问题

    随着业务对Redis的依赖越来越重,数据备份也变得非常重要。众所周知,Redis架构并非MVCC结构,因此想要备份数据,难免需要悲观锁定之后,拷贝内存数据。不过Redis作者设计了一个copy on write的方案,即调用fork,创建出子进程进行数据拷贝,避免了用户态加锁。然而,这个过程其实会在内核侧加锁,依然会给业务性能带来明显抖动。

     

    3. 主从脱节问题

    开源Redis采用主从高可用架构,数据采用异步模式传输。因此主宕机之后,很容易造成数据丢失或不一致。此外,当主节点写入压力较大时,单线程的主从复制很可能无法追平增量数据,就会导致buffer堆积,进一步还可能出现写失败甚至OOM的灾难。虽然Redis能够通过临时生成快照并同步大文件,来尝试追平主从巨大差异,但如前文所述,此时又会引发fork系列问题。

     

    4. fork问题

    fork其实是个非常重的系统调用,虽然是写时拷贝,但是通常也会给他预留一倍的内存。fork工作时还需要加锁拷贝进程页表等信息,对业务的影响非常之大。上述3个问题的背后都有fork的因素,通常需要DBA采用关闭主节点AOF、关闭主节点备份等复杂运维手段来避免。但在主从频繁切换、节点数很多的场景下,运维是非常困难的。甚至在主从脱节场景,理论上毫无办法规避。

     

    5. 容量问题

    开源Redis不适合大规模使用,有两个重要因素限制了其扩展性。首先是fork限制了Redis的垂直扩展能力(Scale Up),数据量越大,fork越慢,对业务的影响就越大,因此单个redis进程可承载的数据量非常有限。其次,低效率的gossip集群管理限制了其水平扩展能力(Scale Out):因为节点数越多,其故障发现的时间越长,并且内部通信的网络风暴成几何级数增加,导致大集群几乎不可用。

    1.2 业界有哪些解决办法?

    以上就是各大企业在开源Redis的生产实践中,真实碰到的经典问题。这些问题限制了开源Redis的大规模应用。因此,近年来业界提出了非常多的解决方案,见下图。

    本质上,Redis是一种KV存储,按照场景其实可以进一步划分为两大阵营:缓存与持久化。

    缓存场景:一般用来存放秒杀、热点事件的数据。比如微博热搜,这类数据是有有效期的,而且可丢。

    持久化场景:在用Redis做缓存的时候,由于其接口简单、功能丰富,大家必然希望将更多重要数据也持久化存放到Redis,比如历史订单、特征工程、位置坐标、机器学习等。这类数据的数据量往往很大、有效期也很长、一般不可丢。

    缓存场景比较简单就是开源Redis,持久化场景业界已有非常多自研产品,比如360ssdb/pika,阿里的tair,腾讯的tendis,当然华为云的高斯Redis也属于自研的持久化Redis

    这里也补充另一个做持久化的理由,从成本考虑,256G内存条价格比256GSSD磁盘高了将近30倍,在可用容量上也有巨大差异。

    1.3 华为云数据库的解法是啥?

    华为云数据库团队吸取开源Redis的经验,选择了自研持久化Redis,即今天分享的主角——高斯Redis。它的一句话定位是:支持Redis协议的NoSQL数据库,而不是缓存。它有两个跟业界完全不一样的特性:

    1. 存算分离。高斯Redis基于华为内部自研分布式存储DFV,提供强大的数据存储能力,包括强一致、弹性扩缩容等高级特性。DFV为何物?它是华为全栈数据服务的基石,比如文件EVS、对象OBS、块存储,还有数据库族、大数据族,都依赖于此,可以想象它的强大及稳定性。
    2. 多模架构。实际上高斯Redis是多模数据库Gauss NoSQL的一员,Gauss NoSQL提供了全栈的分布式KV引擎、用户态文件系统、存储池等技术,只需要在接口上封装Redis协议,即可轻松实现一个全新的NoSQL产品。类似的,我们还提供了MongoDBCassandraInfluxNoSQL引擎。

    2. 为什么选择存算分离?

    在云原生概念铺天盖地的今天,数据库也逐步走向云原生,而它的云原生有一个重要特点就是存算分离。存算分离也代表了数据库上云的最新趋势。

    第一代数据库服务:通过下图可以看到,传统IDC建设时,数据库架设在裸金属之上,由于数据库服务的敏感特殊性,DBA或者研发需要关心机型的选择、磁盘Raid阵列、组网,甚至采购等诸多事项。

    第二代数据库服务:随着虚拟化技术的普及,应用型业务大量上云,数据库也开始上云搬迁,最简单的办法是在虚拟机或容器中运行一个数据库服务即可。这样做的优点很明显,但缺点有两个:一个是通用云盘都是3副本,加上数据库上层的多副本,资源浪费严重;另一个是备机资源浪费,平时无法提供服务。除此以外还有云盘IO性能等问题存在。

    第三代数据库服务:基于存算分离架构,将数据库服务分成CPU密集的计算层和IO密集的存储层。数据的副本管理完全交给存储层,计算层实现无状态转发,既能发挥云的弹性优势,又能全负荷分担。不过缺点也很明显,即基于旧架构改造难度大。

    采用存算分离架构之后,数据库服务就是个分而治之的思想:计算层负责服务化、产品化的各种处理,全程无状态;而存储层,就专注于数据本身的维护,包括副本、容灾、硬件感知、扩缩容等等。

    3. 设计与实现

    接下来讲整体设计与实现,首先是软件架构。高斯Redis计算层的模块如下,主要有cfgsvrproxydatanode。连接计算与存储资源的有RocksDBGeminiFS(自研用户态文件系统),分别负责将kv数据转成sst文件和负责将sst文件下推到DFV的对象存储池中。

    接下来是组网设计。一个租户申请的数据库资源,被我们以反亲和的方式,分布在不同的物理机容器上,都属于同一个租户的相同VPC下。不同用户的数据库资源虽然也有可能共享同一台物理机,但是由于VPC隔离,保证了数据隔离。另外,计算层的数据库资源是独占容器的,而存储层资源是共享物理硬件的。

    接下来解读容灾架构。既然高斯Redis定位是数据库而不是缓存,那它对待数据的态度是严肃的:既实现了region内的3AZ容灾,也提供了跨Region的容灾。

    Region内的容灾,实现了一个容忍AZ级故障的高可用方案。在此故障下,数据依然保持强一致状态,这对企业级应用提供了非常强大的数据安全保障。这套架构的可靠性指标可以满足RPO0RTO小于10s的标准。

    具体的实现原理是,依赖DFV3副本强一致复制能力,计算层也做3AZ的反亲和部署。当用户的一条数据通过proxy写到datanode1上,datanode1通过GeminiFS的用户态文件系统,调用DFVSDK找到一个local azDFV存储节点,和一个距离最近remote azDFV存储节点,组成多数派,写成功后即返回给用户。这样的架构下,不管是计算还是存储的AZ级故障,都对数据的安全性没有任何影响。

    接下来继续讲跨Region级别的容灾。高斯Redis除了提供上述3AZ的强一致方案以外,还提供跨Region级别的容灾,也就是两个实例间的异步容灾。这套方案里,我们增加了一个Rsync-Server的模块,用来订阅主实例上新增的日志,再把日志反解编码成相应的格式,转发给对端的备实例,由备实例回放即可。这套方案,可以实现双向同步、断点续传、冲突解决等等。其中冲突解决,针对不同的Redis数据结构,采用不同的解决算法,保障最终一致性。

    4. 竞争力总结

    最后一节是对高斯Redis的优势总结,主要包括:强一致、高可用、冷热分离、弹性伸缩、高性能。

    首先是强一致特性。

    这一点主要受益于DFV3副本机制,因此写入高斯Redis的数据,在客户端收到回复时,数据就已是3副本强一致的。强一致能力对业务实现非常友好,不需要忍受数据的不一致、不需要校验数据。而开源Redis数据采用异步复制,因此主从之间总是有个差异buffer,如果掉电,这部分数据就会丢失,且在大压力写的时候,还会产生buffer堆积,严重的时候,会导致OOM。因此,高斯Redis的强一致是个非常重要的特点,能为业务提供前后一致的状态,不用担心开源Redis主从切换后的数据一致性问题和丢失问题。

     

    第二个特性是高可用

    高可用是数据库的基本能力,这里之所以要再次强调,是因为高斯Redis的可用性跟其他数据库不同,它做到了可接受N-1个节点故障。实现原理受益于共享存储DFV:当某一个计算节点发生故障挂掉,其维护的slot路由信息,会被剩下的节点自动接管。由于不涉及底层数据的迁移,这个接管过程非常快。以此类推,可以接受N-1个节点故障,且不影响全部数据的读写。当然,计算节点减少会对性能造成一定影响。

    第三个特性是冷热分离

    开源Redis的一个经典使用场景是配合MySQL做冷热分离,但这需要业务实现代码负责实现冷热数据交换,并维护其一致性,这个交付逻辑比较复杂。而高斯Redis实现了它自己的冷热分离,即用户刚写入的和经常访问的数据,都被当做热数据加载到内存中,而非频繁访问的数据则会被淘汰到持久化存储中。因此使用了高斯Redis的业务,不再需要从业务层写代码维护冷热交换逻辑,并且可以得到更好的一致性。

    第四个特性是弹性伸缩

    采用存算分离之后的高斯Redis,可以做到按需扩容,即计算不够扩计算,存储不够扩存储即可。计算资源的扩容也很简单,前面已经提到,这个过程其实不涉及数据的拷贝搬迁,只涉及到元数据的修改,即把相应的slot路由信息(不超过1MB)迁移到新增的节点上即可完成,因此速度是非常快的,秒级完成。而存储资源的扩容更简单,由于底层采用共享存储,大多数情况进行逻辑扩容,这只需要用户在控制台上修改配额即可完成,不涉及到任何数据的搬迁和拷贝。当然也有碰到物理扩容的情形,这种情形一般是我们运维提前发现警戒水位,在这之前做平滑的迁移扩容,该过程对用户透明无感知的。

    第五个特性是高性能

    存算分离的架构看似比较重,链路比较复杂,实则在硬件采用、软件优化上,可以做的更大胆更激进,比如RDMA网络、用户态协议、持久化内存等等。因此受益于这些专属的存储设备,加上我们的计算层全负荷分担架构(不引入从节点,因此性能轻松翻倍),在对比友商的数据量大于内存的存储场景下,我们的性能表现很好。另外,对比开源Redis,在数据小于内存的点查场景下,我们的性能也有很大优势,当然范围查询还待优化中。


    本文作者:华为云数据库GaussDB(for Redis)团队

    杭州/西安/深圳简历投递:yuwenlong4@huawei.com

    GaussDB(for Redis)产品主页:

    https://www.huaweicloud.com/product/gaussdbforredis.html

    更多技术文章,关注GaussDB(for Redis)官方博客:

    https://bbs.huaweicloud.com/community/usersnew/id_1614151726110813

    【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区),文章链接,文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:cloudbbs@huaweicloud.com进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。
    • 点赞
    • 收藏
    • 关注作者

    评论(0

    0/1000
    抱歉,系统识别当前为高风险访问,暂不支持该操作

    全部回复

    上滑加载中

    设置昵称

    在此一键设置昵称,即可参与社区互动!

    *长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

    *长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。