Redis系列之——深入reids优化

Posted 2021-03-16 11014p

转：https://www.jianshu.com/p/978b51ffbbc4

一、redis内存

1、内存占用

info memory

 

info memory

 

127.0.0.1:6379> info memory
# Memory
used_memory:940008
used_memory_human:917.98K
used_memory_rss:1540096
used_memory_rss_human:1.47M
used_memory_peak:940008
used_memory_peak_human:917.98K
used_memory_peak_perc:100.01%
used_memory_overhead:936014
used_memory_startup:835330
used_memory_dataset:3994
used_memory_dataset_perc:3.82%
total_system_memory:1911857152
total_system_memory_human:1.78G
used_memory_lua:37888
used_memory_lua_human:37.00K
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
mem_fragmentation_ratio:1.64
mem_allocator:libc
active_defrag_running:0
lazyfree_pending_objects:0

重要指标：used_memory_rss和used_memory以及它们的比值mem_fragmentation_ratio。
当mem_fragmentation_ratio>1时，说明used_memory_rss-used_memory多出的部分内存并没有用于数据存储，而是被内存碎片所消耗，如果两者相差很大，说明碎片率严重。
当mem_fragmentation_ratio<1时，这种情况一般出现在操作系统把Redis内存交换（Swap）到硬盘导致，出现这种情况时要格外关注，由于硬盘速度远远慢于内存，Redis性能会变得很差。
内存消耗划分

 

内存消耗划分

对象内存：包括key和value对象的内存，尽量避免过长的key和合理使用value的类型。
缓冲内存：分为客户端缓冲、复制积压缓冲区、AOF缓冲区。

 

#客户端缓冲
客户端分为普通客户端、复制从客户端、订阅客户端。默认配置分别为
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
//缓冲区超过256M或者超过64M持续60s，则断开连接
client-output-buffer-limit pubsub 32mb 8mb 60
另外可以设置maxclients（默认为10000）限制连接的客户端数。

#复制积压缓冲区
用于主从复制中部分复制时，repl-backlog-size参数控制，默认1MB。可以设置较大的缓冲区空间，比如100M，避免主从全量复制。

#AOF缓冲区
用于在Redis重写期间保存最近的写入命令，AOF缓冲区空间消耗取决于AOF重写时间和写入命令量。

内存碎片：
Redis默认的内存分配器采用jemalloc，使用不太大小的内存块分配对象。
如尽量采用数字类型或者固定长度字符串等，避免内存碎片。
重启节点可以做到内存碎片重新整理，因此将碎片率过高的主节点转换为从节点，进行安全重启。

另外，执行AOF/RDB重写时Redis创建的子进程，也会内存消耗。

在开启linux的THP配置下，如果父进程有大量写命令，会加重子线程内存拷贝量。
设置sysctl vm.overcommit_memory=1允许内核可以分配所有的物理内存，防止Redis进程执行fork时因系统剩余内存不足而失败。

2、内存管理

config set maxmemory 6GB
//设置最大可用内存，由于内存碎片实际占用系统内存更大。
//超过最大可用内存，redis将执行内存溢出控制策略。

redis内存回收策略分两方面：删除过期键 和 超过最大可用内存溢出控制处理。
（1）、删除过期键
维护每个键精准的过期删除机制会导致消耗大量的CPU，所以redis才有以下两种方式：
惰性删除：
当客户端读取带有超时属性的键时，如果已经超过键设置的过期时间，会执行删除操作并返回空。但这种方式下，当过期键一直没有访问将无法得到及时删除，从而导致内存不能及时释放。
定时删除：
Redis内部维护一个定时任务，默认每秒运行10次，采用了自适应算法，根据键的过期比例、使用快慢两种速率模式回收键。

 

定时删除

快慢两种模式内部删除逻辑相同，只是执行的超时时间不同。慢模式每秒10次，超时判断时间为25s。快模式2s只运行一次，超时时间判断为1毫米。
（2）、内存溢出策略控制

 

config set maxmemory-pol-icy{policy} 动态配置。

noeviction：默认策略，不会删除任何数据，拒绝所有写入操作并返回客户端错误信息（error）OOM command not al-lowed when used memory，此时Redis只响应读操作。
volatile-lru：根据LRU(最近最少使用)算法删除设置了超时属性（expire）的键，直到腾出足够空间为止。如果没有可删除的键对象，回退到noeviction策略。
allkeys-lru：根据LRU算法删除键，不管数据有没有设置超时属性，直到腾出足够空间为止。
allkeys-random：随机删除所有键，直到腾出足够空间为止。
volatile-random：随机删除过期键，直到腾出足够空间为止。
volatile-ttl：根据键值对象的ttl属性，删除最近将要过期数据。如果没有，回退到noeviction策略。

 

溢出处理

频繁执行内存回收成本很高，建议线上Redis内存工作在maxmemory>used_memory状态下。

 

3、内存优化

缩减键值对象：key尽量简短，value可以采用potobuf序列化。
控制键的数量。

 

redisObject内部结构

字符串优化

 

字符串sds结构

字符串内部实现采用空间预分配机制，降低内存再分配次数。

 

字符串追加操作

字符串执行追加操作，会追加操作后字符串对象预分配了一倍容量作为预留空间，造成内存碎片率（mem_fragmentation_ratio）上升。因此，尽量减少字符串频繁修改操作如append、setrange，改为直接使用set修改字符串，降低预分配带来的内存浪费和内存碎片化。
编码优化-ziplist

 

编码优化

 

编码优化

ziplist编码是应用范围最广的一种，可以分别作为hash、list、zset类型的底层数据结构实现。•内部表现为数据紧凑排列的一块连续内存数组。

 

•可以模拟双向链表结构，以O（1）时间复杂度入队和出队。   
•新增删除操作涉及内存重新分配或释放，加大了操作的复杂性。   
•读写操作涉及复杂的指针移动，最坏时间复杂度为O（n2）。  
•适合存储小对象和长度有限的数据。

Redis提供了{type}-max-ziplist-value和{type}-max-ziplist-entries相关参数来做控制ziplist编码转换。
使用ziplist编码类型可以大幅降低内存占用，但影响操作的性能。因此需要考虑时间和空间的平衡，针对性能要求较高的场景使用ziplist，建议长度不要超过1000，每个元素大小控制在512字节以内。
字符串优化-intset

 

intset结构

整数类型划分为三种：int-16、int-32、int-64，尽量保持整数范围一致，如都在int-16范围内。防止个别大整数触发集合升级操作，产生内存浪费。

 

二、redis阻塞

Redis是典型的单线程架构，所有的读写操作都是在一条主线程中完成的，如果发生阻塞，将是噩梦。
阻塞可能的原因：
•内在原因包括：不合理地使用API或数据结构、CPU饱和、持久化阻塞等。
•外在原因包括：CPU竞争、内存交换、网络问题等。

不合理地使用API或数据结构：

slowlog get{n}命令可以获取最近的n条慢查询命令.
redis-cli-h{ip}-p{port}bigkeys 查询大对象

策略：修改为低算法度的命令，如hgetall改为hmget等，禁用keys、sort等命令。优化大对象使用。

CPU饱和：

根据info commandstats统计信息分析出命令不合理开销时间。

ziplist编码后hash结构内存占用会变小，但是操作变得更慢且更消耗CPU。

持久化阻塞：

fork阻塞：
fork操作发生在RDB和AOF重写时，Redis主线程调用fork操作产生共享内存的子进程，由子进程完成持久化文件重写工作。如果fork操作本身耗时过长，必然会导致主线程的阻塞。info stats命令获取到latest_fork_usec指标，表示Redis最近一次fork操作耗时，如果耗时很大，比如超过1秒，则需要做出优化调整。
AOF刷盘阻塞：
当我们开启AOF持久化功能时，文件刷盘的方式一般采用每秒一次，后台线程每秒对AOF文件做fsync操作。当硬盘压力过大时，fsync操作需要等待，直到写入完成。如果主线程发现距离上一次的fsync成功超过2秒，为了数据安全性它会阻塞直到后台线程执行fsync操作完成，这种阻塞行为主要是硬盘压力。