vlambda博客
学习文章列表

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

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

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

内存模型如上图：

对象内存存储 Redis 所有的 key-value 型数据类型，key 对象都是 string 类型，value 对象主要有五种数据类型 String、List、Hash、Set、Zset，不同类型的对象通过对应的编码各种封装，对外定义为 RedisObject 结构体。

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

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

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

string（字符串）：

list（列表）：

set（集合）：

hash（hash列表）：

zset（有序集合）：

| 缓冲内存

①客户端缓存

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

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

repl-backlog-size：默认是 1M，backlog 是一个主从复制的缓冲区，是一个环形 buffer，假设达到设置的阈值，不存在溢出的问题，会循环覆盖。

比如 slave 中断过程中同步数据没有被覆盖，执行增量同步就可以。backlog 设置的越大，slave 可以失连的时间就越长，受参数 maxmemory 限制，正常不要设置太大。

②AOF 缓冲

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

AOF 缓冲没法限制，也不需要限制，因为主线程每次进行 AOF 会对比上次刷盘成功的时间。

如果超过 2s，则主线程阻塞直到 fsync 同步完成，主线程被阻塞的时候，aof_delayed_fsync 状态变量记录会增加。因此 AOF 缓存只会存几秒时间的数据，消耗内存比较小。

| 内存碎片

程序出现内存碎片是个很常见的问题，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 内，超过了说明碎片很多。

| 子进程内存

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

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

| 对象内存优化

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

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

①首先是字符串类型的 3 种编码，int 编码除了自身 object 无需分配内存，object 的指针不需要指向其他内存空间，无论是从性能还是内存使用都是最优的。

embstr 是会分配一块连续的内存空间，但是假设这个 value 有任何变化，那么 value 对象会变成 raw 编码，而且是不可逆的。

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

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

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

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

⑥由于目前大部分 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。

⑦【rehash】: redis 存储底层很多是 hashtable，客户端可以根据 key 计算的 hash 值找到对应的对象。

但是当数据量越来越大的时候，可能就会存在多个 key 计算的 hash 值相同，这个时候这些相同的 hash 值就会以链表的形式存放，如果这个链表过大，那么遍历的时候性能就会下降。

所以 Redis 定义了一个阈值（负载因子 loader_factor = 哈希表中键值对数量 / 哈希表长度），会触发渐进式的 rehash，过程是新建一个更大的新 hashtable，然后把数据逐步移动到新 hashtable 中。

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

优化建议：

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

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

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

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

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

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

| 客户端缓冲优化

客户端缓存是很多内存异常增长的罪魁祸首，大部分都是普通客户端输出缓冲区异常增长导致，我们先了解下执行命令的过程，客户端发送一个或者通过 piplie 发送一组请求命令给服务端，然后等待服务端的响应。

一般客户端使用阻塞模式来等待服务端响应，数据在被客户端读取前，数据是存放在客户端缓存区。

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

异常表现：

优化建议：

| 碎片优化

碎片优化可以降低内存使用率，提高访问效率，在 4.0 以下版本，我们只能使用重启恢复，重启加载 rdb 或者重启通过高可用主从切换实现数据的重新加载可以减少碎片。

在 4.0 以上版本，Redis 提供了自动和手动的碎片整理功能，原理大致是把数据拷贝到新的内存空间，然后把老的空间释放掉，这个是有一定的性能损耗的。

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

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

| 子进程内存优化

前面谈到 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，如果父进程有大量写命令，会加重内存拷贝量，从而造成过度内存消耗。

| 缓冲区异常优化案例

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

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

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

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

可以看到缓冲区内存占用很大，最近的操作命令也是 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，然后统一返回结果。

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

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

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

线上 Redis 集群出现内存使用率超过 95% 的灾难告警，但是该集群是有 190 个节点的集群触发异常内存告警的只有 3 个节点。

所以查看集群对应信息以及监控指标发现如下有用信息：

• 3 个从节点对应的主节点内存没有变化，从节点的内存是逐步增长的。

• 发现集群整体 ops 比较低，说明业务变化并不大，没有发现有效命令突增。

• 主从节点的最大内存不一致，主节点是 6G，从节点是 5G，这个是导致灾难告警的重要原因。

• 在出问题前，主节点比从节点的内存大概多出 1.3G，后面从节点 used_memory 逐步增长到超过主节点内存，但是 rss 内存是最后保持了一样。

• 主从复制出现延迟也内存增长的那个时间段。

处理过程如下：

首先想到的应该是保持主从节点最大内存一致，但是因为主机内存使用率比较高暂时没法扩容，因为想到的是从节点可能什么原因阻塞，所以和业务方沟通是重启下 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 做加减法。

https://github.com/redis/redis/issues/946#issuecomment-13599772

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

Redis 在数据存储、缓存都是做了很巧妙的设计和优化，我们在了解了它的内部结构、存储方式之后，我们可以提前在 key 的设计上做优化。

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