Redis 现网那些坑：用个缓存，还要为磁盘故障买单？

近日，网上一些电商用户出现了库存业务查询超时的现象，深究根源，是其使用的 Redis 云服务底层 SSD 卡硬件故障，影响了 Redis 的稳定性，最终导致业务超时。

此时笔者脑中闪过一连串问号：

那么，缓存 Redis 究竟为啥绕不过磁盘这道坎呢？

从技术角度讲，使用缓存 Redis 还要配磁盘，一方面是因为开源 Redis 依赖持久化机制，保证宕机后能取回一部分数据，另一方面这也是主从同步必不可少的。开源 Redis 提供了两种持久化方案——RDB 和 AOF，其中：

1. RDB 是通过对内存打快照的方式，将数据备份到磁盘。开源 Redis 主从之间全量同步就依赖于 RDB 文件。

2. AOF 是通过日志追加的方式记录数据变化。开源 Redis 宕机重启可用 AOF 文件加载“较为完整”的数据。

想到这里，笔者恍然大悟：电商用户的现网问题，原来就在于 RDB 和 AOF 机制都要进行磁盘 IO，而磁盘故障直接影响了 Redis 的持久化，进而阻塞了 Redis 的正常服务！

除此之外，缓存 Redis 的持久化还有各种缺陷：

1. AOF 写入频率通常只能配置为秒级，在 Redis 动辄十万 QPS 的情况下，宕机时仍会有大量数据无法找回；

2. 数据量越大，重启加载 AOF 越缓慢；

3. RDB 的生成和 AOF 重写都会引发 fork 问题，造成性能抖动。

由此可见，缓存 Redis 的持久化既不稳定、也不可靠，甚至还会因为磁盘性能、fork 问题导致上层业务不稳定。然而出于数据“相对”安全、可靠的需求，缓存 Redis 还真就跨不过磁盘这道坎。

自建 Redis 的朋友们难免遇到这种窘境：最开始配了一个普通磁盘，后来遇到各种持久化阻塞服务的问题，不得不对磁盘进行升级。回顾前文的 Redis 实例故障，我们不难发现：缓存 Redis 的持久化与磁盘问题似乎永远无法令人放心。

那么，是否有一劳永逸的方案，可以和 Redis 持久化带来的问题说拜拜呢？

GaussDB(for Redis)作为华为云主推的企业级 Redis，有着稳定可靠的天然优势，其基于存算分离、多副本强一致的架构，摒弃了 RDB/AOF 机制，彻底解决了开源 Redis 持久化性能不稳定、数据不一致、磁盘不可靠等问题，帮助企业用户真正实现降本增效。

那 GaussDB(for Redis)都有哪些“黑科技”呢？

1. 采用 SPDK 技术，通过用户态、异步、无锁、轮询的方式驱动磁盘，相比开源 Redis 内核态驱动，速度大幅提高。

2. 高性能分布式共享存储池采用 RDMA 和 DPDK 技术，极大提高了系统吞吐量，加速数据处理，降低通信延迟。

3. 采用 SCM 技术，将接近内存的性能和速度，与类似 SSD 的容量和成本结合起来，打造强悍底座。

正是如此，GaussDB(for Redis)在保证数据命令级落盘的同时，能够轻松支持百万级 QPS 的高并发访问，以及亚毫秒级时延。其底层使用高性能分布式共享存储池，不会因磁盘故障而阻塞服务；同时，硬件成本又远低于缓存 Redis，且数据量越大性价比越高。

既然 Redis 离不开持久化、离不开磁盘，那何不选择一款兼具性能与持久化优势的 Redis 数据库呢？就如上文提到的电商场景，GaussDB(for Redis)凭借独有的强一致、稳定性、ACID 事务，不但能轻松搞定“库存”业务，其强大的持久化能力更能够为企业核心数据存储保驾护航。

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

• 更多产品信息，欢迎前往华为云 GaussDB(for Redis)官网

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