Redis 现网那些坑:用个缓存,还要为磁盘故障买单?
本文分享自华为云社区《Redis现网那些坑:用个缓存,还要为磁盘故障买单?》,作者: GaussDB 数据库 。
近日,网上一些电商用户出现了库存业务查询超时的现象,深究根源,是其使用的 Redis 云服务底层 SSD 卡硬件故障,影响了 Redis 的稳定性,最终导致业务超时。
此时笔者脑中闪过一连串问号:
那么,缓存 Redis 究竟为啥绕不过磁盘这道坎呢?
从技术角度讲,使用缓存 Redis 还要配磁盘,一方面是因为开源 Redis 依赖持久化机制,保证宕机后能取回一部分数据,另一方面这也是主从同步必不可少的。开源 Redis 提供了两种持久化方案——RDB 和 AOF,其中:
RDB 是通过对内存打快照的方式,将数据备份到磁盘。开源 Redis 主从之间全量同步就依赖于 RDB 文件。
AOF 是通过日志追加的方式记录数据变化。开源 Redis 宕机重启可用 AOF 文件加载“较为完整”的数据。
想到这里,笔者恍然大悟:电商用户的现网问题,原来就在于 RDB 和 AOF 机制都要进行磁盘 IO,而磁盘故障直接影响了 Redis 的持久化,进而阻塞了 Redis 的正常服务!
除此之外,缓存 Redis 的持久化还有各种缺陷:
AOF 写入频率通常只能配置为秒级,在 Redis 动辄十万 QPS 的情况下,宕机时仍会有大量数据无法找回;
数据量越大,重启加载 AOF 越缓慢;
RDB 的生成和 AOF 重写都会引发 fork 问题,造成性能抖动。
由此可见,缓存 Redis 的持久化既不稳定、也不可靠,甚至还会因为磁盘性能、fork 问题导致上层业务不稳定。然而出于数据“相对”安全、可靠的需求,缓存 Redis 还真就跨不过磁盘这道坎。
自建 Redis 的朋友们难免遇到这种窘境:最开始配了一个普通磁盘,后来遇到各种持久化阻塞服务的问题,不得不对磁盘进行升级。回顾前文的 Redis 实例故障,我们不难发现:缓存 Redis 的持久化与磁盘问题似乎永远无法令人放心。
那么,是否有一劳永逸的方案,可以和 Redis 持久化带来的问题说拜拜呢?
GaussDB(for Redis)作为华为云主推的企业级 Redis,有着稳定可靠的天然优势,其基于存算分离、多副本强一致的架构,摒弃了 RDB/AOF 机制,彻底解决了开源 Redis 持久化性能不稳定、数据不一致、磁盘不可靠等问题,帮助企业用户真正实现降本增效。
那 GaussDB(for Redis)都有哪些“黑科技”呢?
采用 SPDK 技术,通过用户态、异步、无锁、轮询的方式驱动磁盘,相比开源 Redis 内核态驱动,速度大幅提高。
高性能分布式共享存储池采用 RDMA 和 DPDK 技术,极大提高了系统吞吐量,加速数据处理,降低通信延迟。
采用 SCM 技术,将接近内存的性能和速度,与类似 SSD 的容量和成本结合起来,打造强悍底座。
正是如此,GaussDB(for Redis)在保证数据命令级落盘的同时,能够轻松支持百万级 QPS 的高并发访问,以及亚毫秒级时延。其底层使用高性能分布式共享存储池,不会因磁盘故障而阻塞服务;同时,硬件成本又远低于缓存 Redis,且数据量越大性价比越高。
既然 Redis 离不开持久化、离不开磁盘,那何不选择一款兼具性能与持久化优势的 Redis 数据库呢?就如上文提到的电商场景,GaussDB(for Redis)凭借独有的强一致、稳定性、ACID 事务,不但能轻松搞定“库存”业务,其强大的持久化能力更能够为企业核心数据存储保驾护航。
本文作者:华为云数据库 GaussDB(for Redis)团队
更多产品信息,欢迎前往华为云 GaussDB(for Redis)官网
杭州/西安/深圳简历投递:yuwenlong4@huawei.com
版权声明: 本文为 InfoQ 作者【华为云开发者社区】的原创文章。
原文链接:【http://xie.infoq.cn/article/82c7776ddf899991234a802fb】。文章转载请联系作者。
评论