作者：vivo 互联网服务器团队- Tang Wenjian

一、 背景

使用过 Redis 的同学应该都知道，它基于键值对(key-value)的内存数据库，所有数据存放在内存中，内存在 Redis 中扮演一个核心角色，所有的操作都是围绕它进行。

我们在实际维护过程中经常会被问到如下问题，比如数据怎么存储在 Redis 里面能节约成本、提升性能？Redis内存告警是什么原因导致？

本文主要是通过分析 Redis内存结构、介绍内存优化手段，同时结合生产案例，帮助大家在优化内存使用，快速定位 Redis 相关内存异常问题。

二、 Redis 内存管理

本章详细介绍 Redis 是怎么管理各内存结构的，然后主要介绍几个占用内存可能比较多的内存结构。首先我们看下Redis 的内存模型。

内存模型如图：

【used_memory】：Redis内存占用中最主要的部分，Redis分配器分配的内存总量（单位是KB）(在编译时指定编译器，默认是jemalloc)，主要包含自身内存(字典、元数据)、对象内存、缓存，lua内存。

【自身内存】：自身维护的一些数据字典及元数据，一般占用内存很低。

【对象内存】：所有对象都是Key-Value型，Key对象都是字符串，Value对象则包括5种类（String，List，Hash，Set，Zset），5.0还支持stream类型。

【缓存】：客户端缓冲区(普通 + 主从复制 + pubsub)以及aof缓冲区。

【Lua内存】：主要是存储加载的 Lua 脚本，内存使用量和加载的 Lua 脚本数量有关。

【used_memory_rss】：Redis 主进程占据操作系统的内存（单位是KB），是从操作系统角度得到的值，如top、ps等命令。

【内存碎片】：如果对数据的更改频繁，可能导致redis释放的空间在物理内存中并没有释放，但redis又无法有效利用，这就形成了内存碎片。

【运行内存】：运行时消耗的内存，一般占用内存较低，在10M内。

【子进程内存】：主要是在持久化的时候，aof rewrite或者rdb产生的子进程消耗的内存，一般也是比较小。

2.1 对象内存

对象内存存储 Redis 所有的key-value型数据类型，key对象都是 string 类型，value对象主要有五种数据类型String、List、Hash、Set、Zset，不同类型的对象通过对应的编码各种封装，对外定义为RedisObject结构体，RedisObject都是由字典（Dict）保存的，而字典底层是通过哈希表来实现的。通过哈希表中的节点保存字典中的键值对，结构如下：

异常增长原因可能如下几种：

1. 客户端访问大key 导致客户端输出缓存异常增长。
2. 客户端使用monitor命令访问Redis，monitor命令会把所有访问redis的命令持续存放到输出缓冲区，导致输出缓冲区异常增长。
3. 客户端为了加快访问效率，使用pipline封装了大量命令，导致返回的结果集异常大（pipline的特性是等所有命令全部执行完才返回，返回前都是暂存在输出缓存区）。
4. 从节点应用数据较慢，导致输出主从复制输出缓存有很多数据积压，最后导致缓冲区异常增长。

异常表现：

1. 在Redis的info命令返回的结果里面，client部分client_recent_max_output_buffer的值很大。
2. 在执行client list命令返回的结果集里面，omem不为0且很大，omem代表该客户端的输出代表缓存使用的字节数。
3. 在集群中，可能少部分used_memory在监控显示存在异常增长，因为不管是monitor或者pipeline都是针对单个实例的下发的命令。

优化建议：

1. 应用不要设计大key,大key尽量拆分。
2. 服务端的普通客户端输出缓存区通过参数设置，因为内存告警的阈值大部分是使用率80%开始，实际建议参数可以设置为实例内存的5%～15%左右，最好不要超过20%，避免OOM。
3. 非特殊情况下避免使用monitor命令或者rename该命令。
4. 在使用pipline的时候，pipeline不能封装过多的命令，特别是一些返回结果集较多的命令更应该少封装。
5. 主从复制输出缓冲区大小设置参考： 缓冲区大小=（主库写入命令速度 * 操作大小 - 主从库间网络传输命令速度 * 操作大小）* 2。

3.3 碎片优化

碎片优化可以降低内存使用率，提高访问效率，在4.0以下版本，我们只能使用重启恢复，重启加载rdb或者重启通过高可用主从切换实现数据的重新加载可以减少碎片，在4.0以上版本，Redis提供了自动和手动的碎片整理功能，原理大致是把数据拷贝到新的内存空间，然后把老的空间释放掉，这个是有一定的性能损耗的。

【a. redis手动整理碎片】：执行memory purge命令即可。

【b.redis自动整理碎片】：通过如下几个参数控制

• 【activedefrag yes 】：启用自动碎片清理开关
• 【active-defrag-ignore-bytes 100mb】：内存碎片空间达到多少才开启碎片整理
• 【active-defrag-threshold-lower 10】：碎片率达到百分之多少才开启碎片整理
• 【active-defrag-threshold-upper 100 】：内存碎片率超过多少，则尽最大努力整理（占用最大资源去做碎片整理）
• 【active-defrag-cycle-min 25 】：内存自动整理占用资源最小百分比
• 【active-defrag-cycle-max 75】：内存自动整理占用资源最大百分比

3.4 子进程内存优化

前面谈到 AOF rewrite和 RDB 生成动作会产生子进程，正常在两个动作执行的过程中，Redis 写操作没有那么频繁的情况下fork出来的子进程是不会消耗很多内存的，这个主要是因为 Redis 子进程使用了 Linux 的 copy on write 机制，简称COW。

COW的核心是在fork出子进程后，与父进程共享内存空间，只有在父进程发生写操作修改内存数据时，才会真正去分配内存空间，并复制内存数据。

但是有一点需要注意，不要开启操作系统的大页THP（Transparent Huge Pages），开启 THP 机制后，本来页的大小由4KB变为 2MB了。它虽然可以加快 fork 完成的速度( 因为要拷贝的页的数量减少 )，但是会导致 copy-on-write 复制内存页的单位从 4KB 增大为 2MB，如果父进程有大量写命令，会加重内存拷贝量，从而造成过度内存消耗。

四、内存优化案例

4.1 缓冲区异常优化案例

线上业务 Redis 集群出现内存告警，内存使用率增长很快达到100%，值班人员先进行了紧急扩容，同时反馈至业务群是否有大量新数据写入，业务反馈并无大量新数据写入，且同时扩容后的内存还在涨，很快又要触发告警了，业务 DBA 去查监控看看具体原因。

首先我们看used_memory增长只是集群的少数几个实例，同时内存异常的实例的key的数量并没有异常增长，说明没有写入大批量数据导致。

我们再往下分析，可能是客户端的内存占用异常比较大，查看实例 info 里面的客户端相关指标，观察发现output_list的增长曲线和used_memory一致，可以判定是客户端的输出缓冲异常导致。

接下来我们再去通过client list查看是什么客户端导致output增长，客户端在执行什么命令，同时去分析是否访问大key。

执行 client list |grep -i omem=0 发现如下：

id=12593807 addr=192.168.101.1:52086 fd=10767 name= age=15301 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=16173 oll=341101 omem=5259227504 events=rw cmd=get

说明下相关的几个重点的字段的含义：

【id】：就是客户端的唯一标识，经常用于我们kill客户端用到id；
【addr】：客户端信息；
【obl】：固定缓冲区大小(字节)，默认是16K；
【oll】：动态缓冲区大小（对象个数），客户端如果每条命令的响应结果超过16k或者固定缓冲区写满了会写动态缓冲区；
【omem】: 指缓冲区的总字节数；
【cmd】: 最近一次的操作命令。

可以看到缓冲区内存占用很大，最近的操作命令也是get，所以我们先看看是否大key导致(我们是直接分析RDB发现并没有大key)，但是发现并没有大key，而且get对应的肯定是string类型，string类型的value最大是512M，所以单个key也不太可能产生这么大的缓存，所以断定是客户端缓存了多个key。

这个时候为了尽快恢复，和业务沟通临时kill该连接，内存释放，然后为了避免防止后面还产生异常，和业务方沟通设置普通客户端缓存限制，因为最大内存是25G，我们把缓存设置了2G-4G， 动态设置参数如下：

config set client-output-buffer-limit normal 4096mb 2048mb 120

因为参数限制也只是针对单个client的输出缓冲这么大，所以还需要检查客户端使用使用 pipline 这种管道命令或者类似实现了封装大批量命令导致结果统一返回之前被阻塞，后面确定确实会有这个操作，业务层就需要去逐步优化，不然我们限制了输出缓冲，达到了上限，会话会被kill, 所以业务不改的话还是会有抛错。

业务方反馈用的是 C++ 语言 brpc 自带的 Redis客户端，第一次直接搜索没有pipline的关键字，但是现象又指向使用的管道，所以继续仔细看了下代码，发现其内部是实现了pipline类似的功能，也是会对多个命令进行封装去请求redis，然后统一返回结果，客户端GitHub链接如下:

https://github.com/apache/incubator-brpc/blob/master/docs/cn/redis_client.md

总结：

pipline 在 Redis 客户端中使用的挺多的，因为确实可以提供访问效率，但是使用不当反而会影响访问，应该控制好访问，生产环境也尽量加这些内存限制，避免部分客户端的异常访问影响全局使用。

4.2 从节点内存异常增长案例

线上 Redis 集群出现内存使用率超过 95% 的灾难告警，但是该集群是有190个节点的集群触发异常内存告警的只有3个节点。所以查看集群对应信息以及监控指标发现如下有用信息：

1. 3个从节点对应的主节点内存没有变化，从节点的内存是逐步增长的。
2. 发现集群整体ops比较低，说明业务变化并不大，没有发现有效命令突增。
3. 主从节点的最大内存不一致，主节点是6G,从节点是5G，这个是导致灾难告警的重要原因。
4. 在出问题前，主节点比从节点的内存大概多出1.3G，后面从节点used_memory逐步增长到超过主节点内存,但是rss内存是最后保持了一样。
5. 主从复制出现延迟也内存增长的那个时间段。

处理过程：

首先想到的应该是保持主从节点最大内存一致，但是因为主机内存使用率比较高暂时没法扩容，因为想到的是从节点可能什么原因阻塞，所以和业务方沟通是重启下2从节点缓解下，重启后从节点内存释放，降到发生问题前的水平，如上图，后面主机空出了内存资源，所以优先把内存调整一致。

内存调整好了一周后，这3个从节点内存又告警了，因为现在主从内存是一致的，所以触发的是严重告警(>85%)，查看监控发现情况是和之前一样，猜测这个是某些操作触发的，所以还是决定问问业务方这 两个时间段都有哪些操作，业务反馈这段时间就是在写业务，那2个时间段都是在写入，也看了写redis的那段代码，用了一个比较少见的命令append，append是对string类型的value进行追加。

这里就得提下string类型在 Redis 里面是怎么分配内存的：string类型都是都是sds存储，当前分配的sds内存空间不足存储且小于1M时候，Redis会重新分配一个2倍之前内存大小的内存空间。

根据上面到知识点，所以可以大致可以解析上述一系列的问题，大概是当时做 append 操作，从节点需要分配空间从而发生内存膨胀，而主节点不需要分配空间，因为内存重新分配设计malloc和free操作，所以当时有lag也是正常的。

Redis的主从本身是一个逻辑复制，加载 RDB 的过程其实也是拿到kv不断的写入到从节点，所以主从到内存大小也经常存在不相同的情况，特别是这种values大小经常改变的场景，主从存储的kv所用的空间很多可能是不一样的。

为了证明这一猜测，我们可以通过获取一个key(value大小要比较大)在主从节点占用空间的大小，因为是4.0以上版本，所以我们可以使用memory USAGE 去获取大小,看看差异有多少，我们随机找了几个稍微大点的key去查看，发现在有些key从库占用空间是主库的近2倍，有的差不多，有的也是1倍多，rdb解析出来的这个key空间更小，说明从节点重启后加载rdb进行存放是最小的，然后因为某段时间大批量key操作，导致从节点的大批量的key分配的空间不足，需要扩容1倍空间，导致内存出现增长。

到这就分析的其实差不多了，因为append的特性，为了避免内存再次出现内存告警，决定把该集群的内存进行扩容，控制内存使用率在70%以下(避免可能发生的大量key使用内存翻倍的情况)。

最后还有1个问题：上面的used_memory为什么会比memory_rss的值还大呢？（swap是关闭的）。

这是因为jemalloc内存分配一开始其实分配的是虚拟内存，只有往分配的page页里面写数据的时候才会真正分配内存，memory_rss是实际内存占用，used_memory其实是一个计数器，在 Redis做内存的malloc/free的时候，对这个used_memory做加减法。

关于used_memory大于memory_rss的问题，redis作者也做了回答：

https://github.com/redis/redis/issues/946

总结：

在知晓 Redis内存分配原理的情况下，数据库的内存异常问题进行分析会比较快速定位，另外可能某个问题看起来和业务没什么关联，但是我们还是应该多和业务方沟通获取一些线索排查问题，最后主从内存一定按照规范保持一致。

五、总结

Redis在数据存储、缓存都是做了很巧妙的设计和优化，我们在了解了它的内部结构、存储方式之后，我们可以提前在key的设计上做优化。我们在遇到内存异常或者性能优化的时候，可以不再局限于表面的一些分析如：资源消耗、命令的复杂度、key的大小，还可以结合根据Redis的一些内部运行机制和内存管理方式去深入发现是否还有可能哪些方面导致异常或者性能下降。

参考资料

• 书籍《Redis设计与实现》