Redis 内存优化在 vivo 的探索与实践

一、 背景

使用过 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）保存的，而字典底层是通过哈希表来实现的。通过哈希表中的节点保存字典中的键值对，结构如下：

（来源：书籍《Redis设计与实现》）

为了达到极大的提高 Redis 的灵活性和效率，Redis 根据不同的使用场景来对一个对象设置不同的编码，从而优化某一场景下的效率。 

各类对象选择编码的规则如下：

string (字符串)

• 【int】：(整数且数字长度小于20，直接记录在ptr*里面)

• 【embstr】: （连续分配的内存（字符串长度小于等于44字节的字符串））

• 【raw】: 动态字符串(大于44个字节的字符串，同时字符长度小于 512M(512M是字符串的大小限制))

list （列表）

• 【ziplist】：（元素个数小于hash-max-ziplist-entries配置（默认512个），同时所有值都小于hash-max-ziplist-value配置（默认64个字节））

• 【linkedlist】：(当列表类型无法满足ziplist的条件时，Redis会使用linkedlist作为列表的内部实现)

• 【quicklist】：（Redis 3.2 版本引入了 quicklist 作为 list 的底层实现，不再使用 linkedlist 和 ziplist 实现）

set （集合）

• 【intset 】：（元素都是整数且元素个数小于set-max-intset-entries配置（默认512个））

• 【hashtable】：（集合类型无法满足intset的条件时就会使用hashtable）

hash （hash列表）

• 【ziplist】：（元素个数小于hash-max-ziplist-entries配置（默认512个），同时任意一个value的长度都小于hash-max-ziplist-value配置(默认64个字节)）

• 【hashtable】：（hash类型无法满足intset的条件时就会使用hashtable

zset（有序集合）

• 【ziplist】：（元素个数小于zset-max-ziplist-entries配置（默认128个）同时每个元素的value小于zset-max-ziplist-value配置（默认64个字节））

• 【skiplist】：（当ziplist条件不满足时，有序集合会使用skiplist作为内部实现）

2.2 缓冲内存

2.2 1 客户端缓存

客户端缓冲指的是所有接入 Redis 服务的 TCP 连接的输入输出缓冲。有普通客户端缓冲、主从复制缓冲、订阅缓冲，这些都由对应的参数缓冲控制大小（输入缓冲无参数控制，最大空间为1G），若达到设定的最大值，客户端将断开。

【client-output-buffer-limit】： 限制客户端输出缓存的大小，后面接客户端种类(normal、slave、pubsub)及限制大小，默认是0，不做限制，如果做了限制，达到阈值之后，会断开链接，释放内存。

【repl-backlog-size】：默认是1M，backlog是一个主从复制的缓冲区，是一个环形buffer,假设达到设置的阈值，不存在溢出的问题,会循环覆盖，比如slave中断过程中同步数据没有被覆盖，执行增量同步就可以。backlog设置的越大，slave可以失连的时间就越长，受参数maxmemory限制，正常不要设置太大。

2.2 2 AOF 缓冲

当我们开启了 AOF 的时候，先将客户端传来的命令存放在AOF缓冲区，再去根据具体的策略（always、everysec、no）去写入磁盘中的 AOF 文件中，同时记录刷盘时间。

AOF 缓冲没法限制，也不需要限制，因为主线程每次进行 AOF会对比上次刷盘成功的时间；如果超过2s，则主线程阻塞直到fsync同步完成，主线程被阻塞的时候，aof\_delayed\_fsync状态变量记录会增加。因此 AOF 缓存只会存几秒时间的数据，消耗内存比较小。

2.3 内存碎片

程序出现内存碎片是个很常见的问题，Redis的默认分配器是jemalloc ，它的策略是按照一系列固定的大小划分内存空间，例如 8 字节、16 字节、32 字节、…, 4KB、8KB 等。当程序申请的内存最接近某个固定值时，jemalloc 会给它分配比它大一点的固定大小的空间，所以会产生一些碎片，另外在删除数据的时候，释放的内存不会立刻返回给操作系统，但redis自己又无法有效利用，就形成碎片。

内存碎片不会被统计在used\_memory中，内存碎片比率在redis info里面记录了一个动态值mem\_fragmentation\_ratio，该值是used\_memory\_rss / used\_memory的比值，mem\_fragmentation\_ratio越接近1，碎片率越低，正常值在1~1.5内，超过了说明碎片很多。

2.4 子进程内存

前面提到子进程主要是为了生成 RDB 和 AOF rewrite产生的子进程，也会占用一定的内存，但是在这个过程中写操作不频繁的情况下内存占用较少，写操作很频繁会导致占用内存较多。

三、Redis 内存优化

内存优化的对象主要是对象内存、客户端缓冲、内存碎片、子进程内存等几个方面，因为这几个内存消耗比较大或者有的时候不稳定，我们优化内存的方向分为如：减少内存使用、提高性能、减少内存异常发生。

3.1 对象内存优化

对象内存的优化可以降低内存使用率，提高性能，优化点主要针对不同对象不同编码的选择上做优化。

在优化前，我们可以了解下如下的一些知识点：

（1）首先是字符串类型的3种编码，int编码除了自身object无需分配内存，object 的指针不需要指向其他内存空间，无论是从性能还是内存使用都是最优的，embstr是会分配一块连续的内存空间，但是假设这个value有任何变化，那么value对象会变成raw编码，而且是不可逆的。

（2）ziplist 存储 list 时每个元素会作为一个 entry; 存储 hash 时 key 和 value 会作为相邻的两个 entry; 存储 zset 时 member 和 score 会作为相邻的两个entry，当不满足上述条件时，ziplist 会升级为 linkedlist, hashtable 或 skiplist 编码。

（3）在任何情况下大内存的编码都不会降级为 ziplist。

（4）linkedlist 、hashtable 便于进行增删改操作但是内存占用较大。

（5）ziplist 内存占用较少，但是因为每次修改都可能触发 realloc 和 memcopy, 可能导致连锁更新(数据可能需要挪动)。因此修改操作的效率较低，在 ziplist 的条目很多时这个问题更加突出。

（6）由于目前大部分redis运行的版本都是在3.2以上，所以 List 类型的编码都是quicklist,它是 ziplist 组成的双向链表linkedlist ，它的每个节点都是一个ziplist，考虑了综合平衡空间碎片和读写性能两个维度所以使用了个新编码quicklist，quicklist有个比较重要的参数list-max-ziplist-size，当它取正数的时候，正数表示限制每个节点ziplist中的entry数量，如果是负数则只能为-1~-5，限制ziplist大小，从-1~-5的限制分别为4kb、8kb、16kb、32kb、64kb，默认是-2，也就是限制不超过8kb。

（7）【rehash】: redis存储底层很多是hashtable，客户端可以根据key计算的hash值找到对应的对象，但是当数据量越来越大的时候，可能就会存在多个key计算的hash值相同，这个时候这些相同的hash值就会以链表的形式存放，如果这个链表过大，那么遍历的时候性能就会下降，所以Redis定义了一个阈值(负载因子 loader_factor = 哈希表中键值对数量 / 哈希表长度)，会触发渐进式的rehash，过程是新建一个更大的新hashtable，然后把数据逐步移动到新hashtable中。

（8）【bigkey】：bigkey一般指的是value的值占用内存空间很大，但是这个大小其实没有一个固定的标准，我们自己定义超过10M就可以称之为bigkey。

优化建议：

1. key尽量控制在44个字节数内，走embstr编码，embstr比raw编码减少一次内存分配，同时因为是连续内存存储，性能会更好。

2. 多个string类型可以合并成小段hash类型去维护，小的hash类型走ziplist是有很好的压缩效果，节约内存。

3. 非string的类型的value对象的元素个数尽量不要太多，避免产生大key。

4. 在value的元素较多且频繁变动，不要使用ziplist编码，因为ziplist是连续的内存分配，对频繁更新的对象并不友好，性能损耗反而大。

5. hash类型对象包含的元素不要太多，避免在rehash的时候消耗过多内存。

6. 尽量不要修改ziplist限制的参数值，因为ziplist编码虽然可以对内存有很好的压缩，但是如果元素太多使用ziplist的话，性能可能会有所下降。

3.2 客户端缓冲优化

客户端缓存是很多内存异常增长的罪魁祸首，大部分都是普通客户端输出缓冲区异常增长导致，我们先了解下执行命令的过程，客户端发送一个或者通过piplie发送一组请求命令给服务端，然后等待服务端的响应，一般客户端使用阻塞模式来等待服务端响应，数据在被客户端读取前，数据是存放在客户端缓存区，命令执行的简易流程图如下：

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

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，所