Redis的big key问题介绍以及监控手段

本文目录：

1、big key的定义及问题

2、2023年实际生产事故

3、监控手段

4、预防手段

（一）big key的定义及产生的问题

Redis 的big key是指value占用内存空间较大的键值。通常，针对不同的数据类型会用元素个数或者占用空间大小来衡量bigKey：

String：value占用空间超过5MB（实际使用避免超过1MB）；

集合(list，set，zset）：成员数量超过1万个（实际使用避免超过2000个）；

hash：field成员个数1000个，但value总大小超过100M（实际避免超过10MB)；

Big Key对Redis系统性能会带来极其严重的影响，具体问题包括：

1、big key占用较大内存空间，在Redis集群中会造成严重的数据倾斜，存储分布不均匀；

2、当big key同时还是热点key时，还会造成访问倾斜，可能造成单节点访问出现异常；

3、对 big key的操作，尤其是批量操作，较耗时，时间复杂度达到O(N)，会造成命令执行阻塞;

4、阻塞网络，bigkey数据较大，会对服务器网卡、所在网络产生一定的影响；

5、影响持久化。AOF重写和bgsave都会同步fork子进程，因为大key，导致写时复制比较耗时。

（二）2023年实际生产事故

1、A系统

现象：交易超时和成功率低预警，以及机房传输设备有端口心跳告警；

影响：用户相应功能不可用，影响用户体验；

原因：存在bigKey，且进行了批量操作(hgetall，hsetall），在交易并发量增大时，批量查询存储操作对Redis性能影响较大，查询缓慢进而导致交易超时。

分析：尽管Redis在Redis4.0引入了后台多线程，Redis6又引入了IO多线程，但Redis的主要命令执行依然是单线程的。如果对单个key进行批量操作，如hashKey的 hgetall,hsetall，执行的时间复杂度是O(N)，当并发上来的时候，这种操作是非常低效的，很容易造成客户端阻塞。此外也可能会引发网络阻塞。因为每次获取大 key 产生的网络流量较大，举一个极端的例子，一个 key 的大小是 1 MB，每秒访问量为 1000，那么每秒会产生 1000MB 的流量，这对于普通千兆网卡的服务器来说是难以承受的。

总结：

开发者在使用Redis时要考虑性能的问题，使用Redis也并不是万事大吉，一定要遵循相应的开发规范。笔者建议查看阿里的Redis开发规范，里面也提到了对于big key、批量操作等典型的会阻塞整个主线程的问题。

2、B系统

现象：交易成功率低于最低告警值；

影响：用户查询功能报错，引起客诉；

原因：使用Redis时存在两个big key且还是热点key，且这两个key都在同一个master节点上（RedisCluster集群），导致在高峰期间对应节点访问流量过大，造成了严重的访问倾斜。

分析：并发较高的系统切记不可忽视big key，hot key的问题，热点问题就是其中要考虑的因素，尤其是像秒杀这种超高并发场景。如果把活动库存以 key-value这种简单方式存储到Redis中，抢购中就会出现上述的问题。

对于这种问题，我们可以通过两种方式解决。

1）增加一层本地缓存，减少Redis的访问，基本上多级缓存都这么干；

2）考虑到一致性的问题，用不了本地缓存，像秒杀场景的活动库存这种，就可以将热点key分散存储，一个key拆成多个子key存储。比如某电商进行茅台抢购活动，首先将茅台商品活动库存放到Redis中，茅台就是一个热点key，如maotai,1000，此时就可以将热点key分散存储，茅台抢购是需要预约的，可以将所有预约用户进行分组，Redis会根据组存储活动库存，key可以是 maotai:groupId1 300，maotai:groupId2 300，maotai:groupId3 400，通过这种方式把整个流量分散到不同的节点上，减轻单节点压力。

（三）监控手段

检测key本身会是一件非常耗时的工作，为了避免Redis的检测造成实际业务命令的阻塞，进行bigKey检测时不可在master节点进行，可以在从节点或者使用RDB文件快照进行检测。具体方案总结如下：

1、在从节点执行 --bigkeys命令

Redis天然支持bigkey的检索，通过该命令，Redis会统计每种数据类型的排名第一位的bigKey。这种方式的优点是会进行全量扫描，在对Redis业务数据存储不清楚的情况下使用。但它的缺点也是由于全量扫描带来的性能问题，一种解决方式是在该命令后加上时间间隔，即每隔多长时间扫描一次。 --bigkey -i 3，表示每隔100条指令就会休眠3秒。