程序员硬核测评：全方位测评 GaussDB(for Redis) 和开源 Redis

　　正值企业数字化转型全面提速之际，业务需求急速增加，伴随而来的是数据量和并发访问量呈指数级增长，传统关系型数据库在处理海量大数据时显得力不从心。由于局部性原理的限制，在使用传统数据库来处理大数据流，在初始建表时表中大量的数据项被置空，这对于传统数据库来说是灾难性的。在关系型数据库中，建表时须定义表结构，字段动态增减对于性能的影响巨大，同时带有大量空值稀疏矩阵的存储会导致存储成本的急剧增加，这给了NoSql 型数据库以极大发展空间，而Redis作为 NoSql 的翘楚，备受业界追捧。

　　开源版本的Redis 5.0 提供了包括 String、List、Set、ZSet、Hash、Bit Array、HyperLogLog、Geo、Streams 九种数据类型，以及建立在这些数据类型上的相关操作，给开发人员更多的选择空间来表达数据和数据间的相互关系。但开源版Redis从本质上讲并不是一款数据库，主要有以下几方面的弱点：

　　1.使用场景有限，只能达到弱一致性的水平，一般只能在缓存层使用；

　　2.使用成本高，由于开源版Redis使用内存作为存储主体，内存居高不下的价格使搭建Redis集群的成本极高；

　　3.运行不稳定，经常使用开源版Redis的读者肯定了解，在进行如大key替换时、扩容、缩容等操作时，经常遇到阻塞、抖动等问题。

　　于是本文我们选择了在业界有着良好口碑GaussDB(for Redis)进行了对比评测，以向各位读者推荐一款真正质优价廉的Redis。下面我们具体展开聊聊：

　　GaussDB(for Redis)：稳定可靠

　　在使用缓存方案时，用户最害怕见到的场景就是Redis由于各种原因性能下降，使业务流量的压力直接向核心数据库转移，最终造成整个系统的雪崩。可以说运行稳定性是用户在对于缓存数据库选型时需要考虑的首要问题，因此我们选择了切换、重启与备份三个在日常工作中经常会遇到的场景进行开源版本Redis与GaussDB(for Redis)进行整体使用感受层面的对比评测。

　　1.灾备切换场景：首先通过在控制台强行将主节点关机，模拟开源Redis主节点故障与GaussDB(for Redis)单个节点故障，其中特别说明：由于GaussDB(for Redis)采用多个节点同时工作的负载均衡方案，因此没有开源Redis中的主节点概念，因此灾备切换时任选某一节点宕机，即可模拟灾备切换的场景。具体如下：

　　可以看到GaussDB(for Redis)在切换过程中服务会瞬间迁移至备节点，而且切换过程中性能下降也不明显，整体只需要1s就可以恢复正常。而对比开源版Redis在切换时则会出现服务完全中断的情况，平均需要5s才能恢复。可以说GaussDB(for Redis)的表现让我完全不会担心在主节点发生异常时，使整个交易链路全部崩溃的情况，但是开源版Redis，在遇到切换时就会比较提心吊胆了。

　　2. 节点故障恢复场景：节点异常重启是Redis使用中所经常遇到的问题，我们知道开源版Redis服务重启时需要加载元数据也就是RDB，Key值越多RDB也就越大，重启速度就越慢，16G规格的开源版Redis服务重启速度约需要10秒左右，而作为对比GaussDB(for Redis)重启时没有重新加载元数据的步骤，因此重启速度很快，几乎可以在1秒内完成重启操作，而且重启速度不受数据量影响。

　　3. 备份场景：对于开源版Redis来说系统备份会触发fork操作，fork操作是标准的POSIX操作系统接口，调用时会产生内存分配、拷贝等等一系列动作，这会使时延大幅度增长，造成开源版Redis在备份等日常运维操作时出现明显的抖动现象，甚至极端情况下还会使内存使用率大幅飙升，触发操作系统OOM保护使Redis进程异常中止，因此开源版的Redis只能在业务低谷期进行备份操作，对于全天候24小时都存在交易高峰的系统就不适用。不过GaussDB(for Redis)从系统底层解决了备份时的fork问题，备份时根本不需要fork操作，数据随时可备，高峰期也不干扰。

　　从总体的使用感受来看，GaussDB(for Redis)在稳定性方面几乎碾压开源版本Redis的，堪称是用户系统中的定海神针，下面我们再就具体扩容、性能、价格等方面的情况进行详细评测。

　　GaussDB (for Redis)：秒级扩容

　　从事开源Redis运维工作的读者，一般都会有掉进过扩容的坑，由于开源 Redis使用内存作为数据的存储，各节点间使用 Raft 协议进行数据同步，这使开源 Redis在扩容时操作较复杂，尤其在对服务器进行内存扩容时，一般都需要对于所在ECS实例进行重启，这一系列的操作必然伴随着主节点的切换与重启，使服务暂时中断。

　　1.扩容过程中的服务性能对比：开源Redis是弱一致的缓存数据库，数据即使没有落盘持久化也可能向调用方法返回写入成功，因此一旦发生切换，那么难免出现脏读现象，因此扩容可以说是开源版Redis日常运维过程中最令使用者头疼的问题。

　　针对扩容场景我们同样对于GaussDB(for Redis)与开源 Redis也进行了相应评测：

　　2.扩容操作便利性对比：从操作层面上讲GaussDB(for Redis)在扩容时比开源 Redis 简单得多，只需要在华为云的操作台上进行简单操作即可，

　　在笔者近百次不断扩容操作当中，GaussDB(for Redis)从未出现过服务中断及数据丢失的情况，扩容操作秒级完成，外部零感知，对比开源版本，操作复杂需要不断地重启、切换不说，在扩容过程中平均会有25秒左右的服务中断。

　　不仅扩容时不再需要提心吊胆，GaussDB(for Redis)的配套监控系统比开源 Redis 完善，不仅可对请求时延等关键性能指标可视化监控，还可实现故障节点自动摘除、平滑移动、自动告警、自动恢复，给使用者提供了绝佳的运维体验。

　　GaussDB(for Redis)：强悍性能

　　与内存相比，磁盘无论在稳定性还是可维护性上都有非常强大的优势，从本质上讲GaussDB(for Redis)实际上都得益于其磁盘作为数据的存储设备，内存的优势是速度快，笔者在评测之前认为GaussDB(for Redis)可能会比开源版本有差距，但实际的测试结果却证明在相同的规格下GaussDB(for Redis)与开源版本的差距微乎其微。

　　1.一般场景性能对比：在我们测试的16G规格下，GaussDB(for Redis)甚至还略高于开源Redis，具体如下：

　　2.大key替换场景性能对比：而且GaussDB(for Redis)也完全解决了开源 Redis在进行 key 值替换时的卡顿问题。在模拟大key替换的场景下，具体如下：

　　在对大Key进行替换、读写操作时，GaussDB(for Redis)性能几乎没有受到任何影响，这与开源版本动辄下降20%的情况相比，实在令人惊喜。

　　3.GaussDB (for Redis)的性能密码

　　剖析这背后的原因，在于GaussDB(for Redis)通过存储层 Shared Everything 解决了开源 Redis 在批量 key 替换时产生的卡顿问题，GaussDB(for Redis)的存算分离架构不但屏蔽了各个不同独立数据库之间的底层细节，让存储的归存储，计算的归计算，将各种能力封装到模块中，用户任意挑选适合组件，根据自身的业务需求、以极小的成本来定制化数据库服务。在这个过程中还保证了完整的用户体验一致性。

　　GaussDB(for Redis)利用 hash 策略对数据进行均衡，不存在 Full GC 造成的 STW 问题，这些技术方案的运用让GaussDB(for Redis)完美解决了开源版本经常出现的卡顿问题，真正做到了“丝丝顺滑，完全不卡”。GaussDB(for Redis)通过冷热分离技术动态发现热点数据，并将热点数据有序调入内存，在客户看来，几乎感受不到GaussDB(for Redis)与开源Redis时的性能差距。

　　GaussDB(for Redis)有开源Redis不具备的优势，就是不受内存容量限制，支持PB级的缓存集群，规模越大GaussDB(for Redis)的性能还越好，从华为云的官方资料上看，GaussDB(for Redis)性能可以轻松达到百万级的QPS。

　　得益于GaussDB(for Redis)负载均衡的架构方案，只要集群中有一个节点还是可用的，整个集群就能正常对外服务，正常情况下每个节点都可支持写入，这种架构在正常情况下可以保证对外的高性能，在异常时又支持N-1级别的容错特性，在性能及容灾方面的对比GaussDB(for Redis)又是领先于开源版Redis。

　　GaussDB(for Redis)：极致性价比

　　为了对比这两者的性价比，我们采购了某厂商的 2C/16G、4C/64G两种规格的ECS云服务器各3台，搭建开源Redis版本的集群，并与华为云上用同规格的 GaussDB(for Redis)进行价格对比，由于具体性能指标的对比前文已经列出，这里不再加赘述。

　　我们可以看到单位数据量的GaussDB(for Redis)在性价比层面可以比开源Redis平均提高近1倍。

　　从评测结果来看，GaussDB(for Redis)是一款超越开源版本的优秀产品，在各方面的指标几乎全面超越了开源版本，总结上述评测结果如下：

　　由于GaussDB(for Redis)基于华为高性能分布式共享存储池，完美避开开源Redis 的主从堆积、主从不一致、fork 抖动、内存利用率只有 50%、大 key 阻塞、gossip 集群管理等诸多问题，购买的容量全部可用，并且单位数据的使用成本只有开源版本的一半。开发者们，现在不试试GaussDB(for Redis)更待何时？