摘要：聚焦 Redis 的性能分析，思考 Redis 可以通过哪些机制来提高性能，当性能瓶颈发生的时候，我们又能做出哪些优化策略，最终确保业务系统的稳定运行。

本文分享自华为云社区《分析内部运行机制，教你解决Redis性能问题》，作者： 华为云社区精选。

Redis 是一种键值数据库，有着时延低、性能好、数据结构丰富的特点，常用作缓存、排行榜、计数器、 消息队列等，是电商秒杀、聊天系统等业务场景中的“熟客”。

作为一个“缓存中间商”，Redis 的性能问题至关重要，一旦发生操作延迟问题，很容易引起连锁反应。所以本文聚焦 Redis 的性能分析，从 Redis 的基本概念出发，了解 Redis 是什么，它的运行机制，思考 Redis 可以通过哪些机制来提高性能，当性能瓶颈发生的时候，我们又能做出哪些优化策略，最终确保业务系统的稳定运行。

读懂 Redis：缓存神器原来是这样工作的

一个网站总有大量的数据是用户共享的，如果每个用户都去数据库查询，效率就太低了。所以有了新的解决方案：将用户共享数据缓存到服务器的内存中。

举个例子，应用程序们从 MySQL 查询到的数据，会到 Redis 这里登记，后面再需要用的时候，就先查找 Redis 的缓存，无需返回到 MySQL 查找。一套流程下来，为 MySQL 减轻了不小的负担，网络服务的性能显著提升。

Redis 堪称数据库届的万金油，哪里需要往哪里搬，这也得益于它有着丰富的数据结构，以及强大的读写性能。

以数据结构为例，Redis 和其他结构化存储的重要区别便是，它不仅支持字符串，还支持不同类型的抽象数据结构，如列表、映射、集、排序集、HyperLogLogs、位图、流和空间索引等。那么 Redis 是如何做到如此“万能”的，它支持的这些数据结构又是如何从底层实现呢？《三次给你聊清楚Redis》之Redis是个啥 就从非关系型数据库谈起，详细聊了聊这个问题，就像最简单的字符串，Redis 并未沿袭传统 c 语言的惯例，而是单独构建了一种简单的动态字符串抽象类型，并充分利用 SDS 实现。

当然，如果你想进一步了解 Redis 系统的设计理念，比如它通过什么机制将数据缓存到内存中，开发大系统必备技术之Redis技术学习与研究或许会给你一些启发，作者谈到了 Redis 的历史、流行度、设计思想，并通过支持 Redis 的 Java 客户端 Jedis ，用详尽的代码案例一步步演示了它支持的数据类型使用方法，它的事务特性、集群等等，更为具象地了解 Redis 的特点。

当我们对 Redis 的基本原理了然于胸后，再针对业务场景进行优化时，也能更合理地使用各种 Redis 命令。

Redis 性能：祸福相依的内部运行机制

Redis 的最大特点是使用内存来存储数据，当内存超过物理内存的限制后，内存数据会和磁盘产生频繁的交换，最终导致 Redis 性能急剧下降。所以在生产环境中我们通过配置参数 maxmemoey 来限制使用的内存大小。 在有趣的Redis：缓存被我写满了，该怎么办？ 中，作者详细解释了 2 个常见的缓存淘汰算法 LRU 算法和 LFU 算法，如何删除那些没用的数据。

另一方面，Redis 为了把内存中的数据持久到磁盘上，也提供了完善的持久化机制，主要包括 2 种：

• RDB：产生一个数据快照文件

• AOF：实时追加命令的日志文件

但是如果配置不合理，持久化会占用过多内存从而影响性能。举个例子，如果 AOF 的刷盘时机设置为每次写入都刷盘，由于每次写命令都需要写入文件并刷到磁盘中才会返回，当写入量很大时，会增加磁盘 IO 的负担，大大降低 Redis 的写入性能。Redis 持久化是如何做的？一文聊聊 RDB和AOF对比分析 谈到了这两种持久化机制对 Redis 性能的影响，建议大家针对不同的业务场景选择合适的持久化方式。

在讨论 Redis 性能问题的时候，不得不提的一点是它的单线程结构，这里的单线程指的是执行命令 ，比如一条命令从客户端到达服务端不会立刻被执行，而是会进入一个队列中等待，每次只会有一条指令被选中执行。【Redis破障之路】：Redis单线程架构 详细分析了单线程模型的 Redis 为什么性能如此之高，能达到每秒万级别的处理能力，简单透露两点：纯内存访问、I/O 多路复用技术，具体可以阅读文章。而 Redis 的单线程架构，也意味着网络问题会对它的性能产生一定的影响。

另外，当业务规模扩大，单个 Redis 服务无法承载的时候，我们常常会用分布式架构来提高 Redis 的性能，Redis主从复制以及哨兵的原理解读 和 Redis Sentinel 源码：Redis的高可用模型分析 都讨论了主从模式下的关键功能：哨兵，通过对其源码的理解，详细说明了哨兵的代码实现方式，并学会使用哨兵功能解决主节点的写能力、存储能力限制等等。

除此之外，诸如数据结构的复杂度、网络带宽、操作系统以及硬件本身都会对 Redis 的性能产生影响，它的性能问题几乎涵盖了 CPU、内存、网络、磁盘的方方面面，再此不一一赘述。

综上，我们分析了影响 Redis 性能的一些关键内部机制，比如它的缓存淘汰算法；它的持久化会占用过多内存从而影响性能；它的单线程架构等。通过了解 Redis 的这些内部实现原理，也能进一步帮助大家排查它的性能问题。

Redis 调优：宕机怎么办？收下这几颗灵丹妙药

下面，我们将给出一些应对 Redis 性能问题的解决方案。

以常见的缓存问题为例，通常情况下，Redis 缓存层由于某种原因宕机后，所有的请求会涌向存储层，短时间内的高并发请求可能会导致存储层挂机，称之为“Redis 雪崩”。Redis缓存异常应对方案分析 有针对性的总结了 Redis 发生缓存穿透、雪崩、击穿情况时，能够有效应对的解决方案，比如不要给访问频繁的热点数据设置过期时间，从而解决 Redis 实例没有起到缓存层作用的问题。

大 key 也是影响 Redis 性能的关键因素，如果一个 key 写入的 value 非常大，那么 Redis 在分配内存时就会比较耗时。同样的，当删除这个 key 时，释放内存也会比较耗时，这种类型的 key 我们一般称之为 大 key。 在 分布式缓存数据库Redis大KEY问题定位及优化建议 中，作者就针对数据库报错 OOM 来一步步分析大 key 的问题，先是查看 Redis 集群内存监控指标，确认内存异常分片，然后通过在线 &离线工具分析，结果显示大 key 导致数据大小分布不均。对此作者给出了两个方案：短期是删除查询到的 key，长期是对大 key 进行拆分。

另一个经常被诟病性能问题的是 fork， fork 是开源 Redis 的一个重要依赖，当 Redis 开启了后台 RDB 和 AOF rewrite 后，在执行时，它们都需要主进程创建出一个子进程进行数据的持久化，fork 就是创建子进程的系统调用函数。

在华为云 GaussDB(for Redis)服务团队支撑某客户业务上云的过程中 ，就发现了由 fork 引发的时延抖动问题，文章一场由fork引发的超时，让我们重新探讨了Redis的抖动问题 还原了当时的场景，探究了 fork 对性能的影响，包括业务抖动、内存率利用率降低和实例容量受限。比如，在电商大促、热点事件等业务高峰时发生上述 fork，会导致 Redis 阻塞，进而对业务造成雪崩的影响。

团队通过修改日志、系统性排查整改代码中的 fork 调用，最后在新版本 GaussDB(for Redis)中解决了该问题，并清零了内部的 fork 使用，与原生 Redis 相比，彻底解决了 fork 的性能隐患。

其实，考虑到业务场景越来越复杂，原生 Redis 出现性能瓶颈难以避免。这时候，最简单粗暴的解决方法就是使用商业版本的 Redis，一劳永逸解决可能存在的性能问题。

在 GaussDB(for Redis)与原生Redis集群的性能对比 中，就比较了华为云自研 Redis 和原生 Redis 集群在 X86 架构下的性能测试报告，结果表明 GaussDB(for Redis)在性能、抗写和存储成本上的优势明显。

从相识到相惜：Redis与计算存储分离四部曲 进一步从技术角度拆解分析了 GaussDB(for Redis)如何在存算分离的架构下，实现强一致、秒扩容、超可用、低成本。以强一致为例，Redis 遇到流量压力进行主从切换时很容易发生数据不同步问题，GaussDB ( for Redis)就在存储层（DFV 层）去进行强一致的数据同步，而非计算层，这样就避免了任何中间态下的数据的不一致，再也不用担心宕机导致数据丢失。更多的技术细节揭秘，也可以阅读这组专题高斯Redis揭秘系列文章，更全面的认识 GaussDB ( for Redis)。

Redis 的性能问题，涉及到的技术细节很多，本专题只是列出了一些较为典型的问题，希望读者能够通过上述提及的技术文章，对它有更深入的认识，学会从底层运行机制去思考 Redis 的性能调优。

点击关注，第一时间了解华为云新鲜技术~