Redis内存优化

Redis内存优化

1.内存消耗

1.1内存使用统计

属性名	属性说明
used_memory	Redis 分配器分配的内存总量，也就是内部存储的所有数据内存占用量
used_memory_human	以可读的格式返回 used_memory
used_memory_rss	从操作系统的角度显示 Redis 进程占用的物理内存总量
used_memory_rss_human	used_memory_rss 的用户易读格式的显示
used_memory_peak	内存使用的最大值，表示 used_memory 的峰值
used_memory_peak_human	以可读的格式返回 used_memory_peak的值
used_memory_lua	Lua引擎所消耗的内存
mem_fragmentation_ratio	used_memory_rss/used_memory 比值，表示内存碎片率
mem_allocator	Redis所使用的内存分配器。默认jemalloc

mem_fragmentation_ratio < 1 表示Redis内存分配超出了物理内存，操作系统正在进行内存交换，内存交换会引起非常明显的响应延迟；
mem_fragmentation_ratio > 1 是合理的；
mem_fragmentation_ratio > 1.5 说明Redis消耗了实际需要物理内存的150%以上，其中50%是内存碎片率，可能是操作系统或Redis实例中内存管理变差的表现

1.2 内存消耗划分

Redis进程的内存消耗主要包括：自身内存 + 对象内存 + 缓冲内存 + Lua内存+内存碎片。

image.png

1.2.1 自身内存

Redis自身内存消耗非常少，通常used_memory在800KB左右，used_memory_rss在3M左右。Redis的内存消耗主要在于后面三个。（used_memory和used_memory_rss的概念在下面介绍）

1.2.2 对象内存

对象内存是Redis内存占用最大的一块，存储着用户的所有数据，还包括慢查询日志等Redis帮我们维护的一些内存数据。

image.png

1. key: 不要过长，量大不容忽视(redis3: embstr 39字节)
2. value: ziplist、intset等优化方式

1.2.3 缓冲内存

缓冲内存主要包括：客户端缓冲、复制积压缓冲、AOF重写缓冲。

image.png

客户端缓冲区

客户端缓冲区指的是所有连到Redis服务器的TCP连接的输入缓冲和输出缓冲。

Redis为每个客户端分配了输入缓冲区，用于临时保存客户端发过来的命令，同时Redis服务器会从输入缓冲区中拉取命令执行，输入缓冲区为客户端向服务端发送的命令提供了缓冲的功能。输入缓冲区大小无法控制，每个客户端的输入缓冲区最大空间为1G，如果超出将断开连接。

image.png


同样的Redis为每个客户端分配了输出缓冲区，用于临时保存服务端执行的命令结果，同时Redis服务器会从输出缓冲区中拉取结果返回到客户端，输出缓冲区为服务端向客户端返回结果提供了缓冲。


输出缓冲区根据客户端的类型又划分为三种：普通客户端、发布订阅客户端、从客户端（Redis复制的slave客户端）。每种客户端的输出规则也不一样，这里就不细说了。

输出缓冲区配置

对应的配置规则是

client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds>

<class>：客户端类型，分为三种(a )normal：普通客户端 (b) slave：从节点用于复制，伪装成客户端 (c) pubsub：发布订阅客户端
<hard limit>：如果客户端使用的输出缓冲区大于<hard limit>,客户端会被立即关闭。
<soft limit> 和 <soft seconds>：如果客户端使用的输出缓冲区超过了<soft limit>并且持续了<soft limit>秒，客户端会被立即关闭

普通客户端缓冲区

1. 默认: client-output-buffer-limit normal 0 0 0
2. 默认：没有限制客户端缓冲

3. 注意：防止大的命令或者monitor

   
   image.png

slave客户端缓冲区

1. 默认：client-output-buffer-limit slave 256mb 64mb 60
2. 阻塞：主从延迟较高，或者从节点过多
3. 注意：主从网络，从节点不要超过2个

pub客户端缓冲区

1. 默认：client-output-buffer-limit pubsub 32mb 8mb 60
2. 阻塞：生产大于消费

3. 注意：根据实际场景适当调试

   
   image.png

复制积压缓冲区

Redis在2.8版本之后提供了一个可重用的固定大小的缓冲区用于实现增量复制的功能，根据repl-backlog-size参数来控制，默认大小1MB。


对于复制积压缓冲区主节点只有一个，所有从节点共享一个，这个缓冲区可以有效地避免全量复制。

image.png

注意：此部分内存独享，考虑部分复制，默认1MB，可以设置更大

AOF重写缓冲区

AOF重写缓冲区用于在AOF重写期间保存写命令，所以AOF重写缓冲区的大小取决于AOF的时间以及AOF重写期间的写命令数量。


等到AOF重写完成之后，会将AOF重写缓冲区中的数据写到AOF文件，从而清空AOF重写缓冲区。

image.png

注意：AOF重写期间，AOF的缓冲区，没有容量限制

1.2.4 内存碎片

1. 必然存在：jemalloc
2. 优化方式：

• 避免频繁更新操作：append、setrange等
• 安全重启，例如redis sentinel和redis cluster等。

1.3 子进程内存消耗

1. 必然存在：fork(bgsave和bgrewriteof)
2. 优化方式：

• 去掉THP特性：即父进程在复制相关内存时由原来的4k（内存页单位）变成2M，如果父进程有大量写，会加重内存拷贝，从而造成过度内存消耗。因此需要关闭THP功能。

• 观察写入量：copy-on-write

• overcommit_memory=1 保证fork的顺利完成

2.内存管理

2.1 设置内存上限

注意：定义实例最大内存，便于管理机器内存，一般要预留30%

image.png

2.2 动态调整内存上限

redis > config set maxmemory 2GB
redis > config rewrite

2.3 内存回收策略

2.3.1删除过期键值

通常删除某个key，我们有如下三种方式进行处理。

1、定时删除

在设置某个key 的过期时间同时，我们创建一个定时器，让定时器在该过期时间到来时，立即执行对其进行删除的操作。

优点：定时删除对内存是最友好的，能够保存内存的key一旦过期就能立即从内存中删除。

缺点：对CPU最不友好，在过期键比较多的时候，删除过期键会占用一部分 CPU 时间，对服务器的响应时间和吞吐量造成影响。

2、惰性删除

设置该key 过期时间后，我们不去管它，当需要该key时，我们在检查其是否过期，如果过期，我们就删掉它，反之返回该key。

优点：对 CPU友好，我们只会在使用该键时才会进行过期检查，对于很多用不到的key不用浪费时间进行过期检查。

缺点：对内存不友好，如果一个键已经过期，但是一直没有使用，那么该键就会一直存在内存中，如果数据库中有很多这种使用不到的过期键，这些键便永远不会被删除，内存永远不会释放。从而造成内存泄漏。

3、定期删除

每隔一段时间，我们就对一些key进行检查，删除里面过期的key。

优点：可以通过限制删除操作执行的时长和频率来减少删除操作对 CPU 的影响。另外定期删除，也能有效释放过期键占用的内存。

缺点：难以确定删除操作执行的时长和频率。
如果执行的太频繁，定期删除策略变得和定时删除策略一样，对CPU不友好。
如果执行的太少，那又和惰性删除一样了，过期键占用的内存不会及时得到释放。
另外最重要的是，在获取某个键时，如果某个键的过期时间已经到了，但是还没执行定期删除，那么就会返回这个键的值，这是业务不能忍受的错误。

2.3.2内存溢出控制策略

超过maxmemory后触发相应策略，由maxmemory-policy控制
当Redis所使用的内存达到 maxmemory 之后会触发相应的溢出控制策略，Redis支持 6 种策略：

• noeviction：当内存使用达到阈值的时候，所有引起申请内存的命令会报错。
• allkeys-lru：在所有键中采用lru算法删除键，直到腾出足够内存为止。
• volatile-lru：在设置了过期时间的键中采用lru算法删除键，直到腾出足够内存为止。
• allkeys-random：在所有键中采用随机删除键，直到腾出足够内存为止。
• volatile-random：在设置了过期时间的键中随机删除键，直到腾出足够内存为止。
• volatile-ttl：在设置了过期时间的键空间中，具有更早过期时间的key优先移除。

3.内存优化

3.1. 内存分布

3.2. 数据结构优化

合理选择数据结构

例子

需求：计算网站每天独立用户数
选择：集合（数据信息丰富）、BitMaps、HyperLogLog （解决海量数据统计问题，缺点不精确）

内部编码

image.png

例子

需求：picId=>userId(10亿)
方案：

1. 全部string: set picId userId
2. 一个hash:hset allPics picId userId
3. 若干个小hash: hset picId/100 picId%100 userId

image.png

三种方案优缺点对比

方案	优点	缺点
全string	编程简单	浪费内存、全量获取较为复杂
全hash	暂无	浪费内存、bigkey
分段hash	节省内存	编程复杂、超时问题

3.3. 客户端缓冲区优化

内存暴增现象

image.png

分析发现并不是以下原因照成
1.批量写入（key-value）
2.主从不一致

实际上可能收到的报警

client_longest_output_list 实际值为230096，大于预设值1000

image.png

找到omem为xxx的客户端连接：redis-cli client list | grep -v "omem=xxx"

处理和预防

1. 处理：直接干掉对应的业务方
2. 预防：
   运维层面：线上Redis禁用monitor(rename-command)
   运维层面：适度限制缓冲区大小
   开发层面：理解monitor的原理，也可以短暂寻找热点key(本地执行)

3.4 其他方法

1. 不要忽视key长度：1亿个键，一个字节也是节省。
   user:friends:notify:{id} --------------> u:f:n:{id}

2.序列化和压缩方法：拒绝java原生，采用protobuf、kryo、snappy等

特别感谢：

carlosfu