Redis大Key处理

发表于： 分类于：
字数： 2616 阅读：≈ 6分钟 浏览：

定义

以Key的大小和Key中成员的数量来综合判定，例如：

  1. Key本身的数据量过大：一个String类型的Key，它的值为5 MB。

  2. Key中的成员数过多：一个ZSET类型的Key，它的成员数量为10,000个。

  3. Key中成员的数据量过大：一个Hash类型的Key，它的成员数量虽然只有1,000个但这些成员的Value（值）总大小为100 MB。

大key影响

  1. 客户端超时阻塞。Redis 执行命令是单线程处理，操作大 key 时会比较耗时，从客户端这一视角看，就是很久很久都没有响应。进而可能引发同步中断或主从切换，同时易波及相关的服务。如果使用 del 删除大 key 时，会阻塞工作线程。

  2. 内存达到maxmemory参数定义的上限引发操作阻塞或重要的Key被逐出，甚至引发内存溢出（Out Of Memory）。

  3. 内存分布不均。集群架构下，某个数据分片的内存使用率远超其他数据分片，无法使数据分片的内存资源达到均衡。集群模型在 slot 分片均匀情况下，会出现数据和查询倾斜情况，部分有大 key 的 Redis 节点占用内存多，QPS 也会比较大。

  4. 引发网络阻塞。每次获取大 key 产生的网络流量较大，如果一个 key 的大小是 1 MB，每秒访问量为 1000，那么每秒会产生 1000MB 的流量，这对于普通千兆网卡的服务器来说是灾难性的。

大 key 持久化影响

当应用程序向文件写入数据时，内核通常先将数据复制到内核缓冲区中，然后排入队列，然后由内核决定何时写入硬盘。

当使用 Always 策略的时候，如果写入是一个大 Key，主线程在执行 fsync() 函数的时候，阻塞的时间会比较久，因为当写入的数据量很大的时候，数据同步到硬盘这个过程是很耗时的。

当使用 Everysec 策略的时候，由于是异步执行 fsync() 函数，所以大 Key 持久化的过程（数据同步磁盘）不会影响主线程。

当使用 No 策略的时候，由于永不执行 fsync() 函数，所以大 Key 持久化的过程不会影响主线程。

会导致阻塞父进程

  1. 创建子进程的途中，要复制父进程的页表等数据结构，阻塞的时间跟页表的大小有关，页表越大，阻塞的时间也越长；

  2. 创建完子进程后，如果子进程或者父进程修改了共享数据，就会发生写时复制，这期间会拷贝物理内存，如果内存越大，自然阻塞的时间也越长；

当 AOF 日志写入了很多的大 Key，AOF 日志文件的大小会很大，那么很快就会触发 AOF 重写机制。

AOF 重写机制和 RDB 快照（bgsave 命令）的过程，都会分别通过 fork() 函数创建一个子进程来处理任务。

fork子进程处理过程

  1. 在创建子进程的过程中，操作系统会把父进程的「页表」复制一份给子进程，这个页表记录着虚拟地址和物理地址映射关系，而不会复制物理内存，也就是说，两者的虚拟空间不同，但其对应的物理空间是同一个。子进程就共享了父进程的物理内存数据了，这样能够节约物理内存资源，页表对应的页表项的属性会标记该物理内存的权限为只读。

  2. 随着 Redis 存在越来越多的大 Key，那么 Redis 就会占用很多内存，对应的页表就会越大。

  3. 在通过 fork() 函数创建子进程的时候，虽然不会复制父进程的物理内存，但是内核会把父进程的页表复制一份给子进程，如果页表很大，那么这个复制过程是会很耗时的，那么在执行 fork 函数的时候就会发生阻塞现象。

  4. fork 函数是由 Redis 主线程调用的，如果 fork 函数发生阻塞，那么意味着就会阻塞 Redis 主线程。由于 Redis 执行命令是在主线程处理的，所以当 Redis 主线程发生阻塞，就无法处理后续客户端发来的命令。

  • PS：我们可以执行 info 命令获取到 latest_fork_usec 指标，表示 Redis 最近一次 fork 操作耗时。

大key产生的原因

  1. 在不适用的场景下使用Redis，易造成Key的value过大，如使用String类型的Key存放大体积二进制文件型数据；

  2. 业务上线前规划设计不足，没有对Key中的成员进行合理的拆分，造成个别Key中的成员数量过多；

  3. 未定期清理无效数据，造成如HASH类型Key中的成员持续不断地增加；

  4. 使用LIST类型Key的业务消费侧发生代码故障，造成对应Key的成员只增不减。

如何找出大key

  1. 使用redis-cli命令客户端，连接Redis服务的时候，加上 —bigkeys 参数，可以扫描每种数据类型数量最大的key。

redis-cli -h 127.0.0.1 -p 6379 —bigkeys

  1. 使用开源工具Redis RDB Tools，分析RDB文件，扫描出Redis大key。

例如：输出占用内存大于1kb，排名前3的keys。

rdb —commond memory —bytes 1024 —largest 3 dump.rbd
  1. 通过在业务层增加相应的代码对Redis的访问进行记录并异步汇总分析。

对不同数据类型的目标Key，分别通过如下风险较低的命令进行分析，来判断目标Key是否符合大Key判定标准。

STRING类型：执行STRLEN命令，返回对应Key的value的字节数。

LIST类型：执行LLEN命令，返回对应Key的列表长度。

HASH类型：执行HLEN命令，返回对应Key的成员数量。

SET类型：执行SCARD命令，返回对应Key的成员数量。

ZSET类型：执行ZCARD命令，返回对应Key的成员数量。

如何优化大key

对大Key进行拆分

例如将含有数万成员的一个HASH Key拆分为多个HASH Key，并确保每个Key的成员数量在合理范围。

在Redis集群架构中，拆分大Key能对数据分片间的内存平衡起到显著作用。

降低单key的大小，读取可以用mget批量读取。

对大Key进行清理

将不适用Redis能力的数据存至其它存储，并在Redis中删除此类数据。使用UNLINK命令删除大key，UNLINK命令是DEL命令的异步版本，它可以在后台删除Key，避免阻塞Redis实例。

对过期数据进行定期清理

堆积大量过期数据会造成大Key的产生。

例如在HASH数据类型中以增量的形式不断写入大量数据而忽略了数据的时效性。可以通过定时任务的方式对失效数据进行清理。

在清理HASH数据时，建议通过HSCAN命令配合HDEL命令对失效数据进行清理，避免清理大量数据造成Redis阻塞。

数据压缩

使用String类型的时候，使用压缩算法减少value大小。或者是使用Hash类型存储，因为Hash类型底层使用了压缩列表数据结构。

设置合理的过期时间

为每个key设置过期时间，并设置合理的过期时间，以便在数据失效后自动清理，避免长时间累积的大Key问题。

启用内存淘汰策略

启用Redis的内存淘汰策略，例如LRU（Least Recently Used，最近最少使用），以便在内存不足时自动淘汰最近最少使用的数据，防止大Key长时间占用内存。

数据分片

例如使用Redis Cluster将数据分散到多个Redis实例，以减轻单个实例的负担，降低大Key问题的风险。