GaussDB(for Redis)揭秘第12期：2021最新架构分享

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

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

for Redis)揭秘第12期：2021最新架构分享" />

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，持久化场景业界已有非常多自研产品，比如360的ssdb/pika，阿里的tair，腾讯的tendis，当然的高斯Redis也属于自研的持久化Redis。

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

1.3 数据库的解法是啥？

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

1、存算分离。高斯Redis基于华为内部自研分布式存储DFV，提供强大的数据存储能力，包括强一致、弹性扩缩容等高级特性。DFV为何物？它是华为全栈数据服务的基石，比如文件EVS、对象OBS、块存储，还有数据库族、大数据族，都依赖于此，可以想象它的强大及稳定性。

2、多模架构。实际上高斯Redis是多模数据库Gauss NoSQL的一员，Gauss NoSQL提供了全栈的分布式KV引擎、用户态文件系统、存储池等技术，只需要在接口上封装Redis协议，即可轻松实现一个全新的NoSQL产品。类似的，我们还提供了MongoDB、Cassandra、Influx等NoSQL引擎。

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

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

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

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

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

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

3. 设计与实现

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

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

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

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

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

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

4. 竞争力总结

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

首先是强一致特性。

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

第二个特性是高可用。

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

第三个特性是冷热分离。

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

第四个特性是弹性伸缩。

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

第五个特性是高性能。

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

5. 结束语

本文作者：高斯Redis团队。

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