共计 4705 个字符，预计需要花费 12 分钟才能阅读完成。
前言：
本文依据华为云 NoSQL 数据库架构师余汶龙，在往年的中国零碎架构师大会 SACC 上的演讲整顿而成，内容如下。
本次分享的纲要分成如下四个局部：
- 什么是 GaussDB(for Redis)？
- 为什么抉择存算拆散
- 设计与实现
- 竞争力总结
什么是 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 数据库，而不是缓存。它有两个跟业界齐全不一样的个性：
- 存算拆散。高斯 Redis 基于华为外部自研分布式存储 DFV，提供弱小的数据存储能力，包含强统一、弹性扩缩容等高级个性。DFV 为何物？它是华为全栈数据服务的基石，比方文件 EVS、对象 OBS、块存储，还有数据库族、大数据族，都依赖于此，能够设想它的弱小及稳定性。
- 多模架构。实际上高斯 Redis 是多模数据库 Gauss NoSQL 的一员，Gauss NoSQL 提供了全栈的分布式 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 官网首页：官网首页。
点击关注，第一工夫理解华为云陈腐技术~
