GaussDB(for Redis) 揭秘：Redis 存算分离架构最全解析

Arce

　　

　　​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​摘要：本文根据华为云 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，持久化场景业界已有非常多自研产品，比如 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 的一员，GaussNoSQL 提供了全栈的分布式 KV 引擎、用户态文件系统、存储池等技术，只需要在接口上封装 Redis 协议，即可轻松实现一个全新的 NoSQL 产品。类似的，我们还提供了 MongoDB、Cassandra、InfluxDB 等 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 的全部内容，更多内容请参考高斯 Redis 官方博客：官方博客 和高斯 Redis 官方首页：官方首页 。
　　点击关注，第一时间了解华为云新鲜技术~