Redis中什么是Big Key(大key)问题?如何解决Big Key问题?

目录
  • 一、什么是Big Key?
  • 二、Big Key产生的场景?
  • 三、Big Key的危害?
  • 四、如何识别Big Key?
  • 五、如何解决Big Key问题?
  • 补充知识:key设计
  • 总结

一、什么是Big Key?

通俗易懂的讲,Big Key就是某个key对应的value很大,占用的redis空间很大,本质上是大value问题。key往往是程序可以自行设置的,value往往不受程序控制,因此可能导致value很大。

redis中这些Big Key对应的value值很大,在序列化/反序列化过程中花费的时间很大,因此当我们操作Big Key时,通常比较耗时,这就可能导致redis发生阻塞,从而降低redis性能。

用几个实际的例子对大Key的特征进行描述:

● 一个String类型的Key,它的值为5MB(数据过大);

● 一个List类型的Key,它的列表数量为20000个(列表数量过多);

● 一个ZSet类型的Key,它的成员数量为10000个(成员数量过多);

● 一个Hash格式的Key,它的成员数量虽然只有1000个但这些成员的value总大小为100MB(成员体积过大);

在实际业务中,大Key的判定仍然需要根据Redis的实际使用场景、业务场景来进行综合判断。通常都会以数据大小与成员数量来判定。

二、Big Key产生的场景?

1、redis数据结构使用不恰当

将Redis用在并不适合其能力的场景,造成Key的value过大,如使用String类型的Key存放大体积二进制文件型数据。

2、未及时清理垃圾数据

没有对无效数据进行定期清理,造成如HASH类型Key中的成员持续不断的增加。即一直往value塞数据,却没有删除机制,value只会越来越大。

3、对业务预估不准确

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

4、明星、网红的粉丝列表、某条热点新闻的评论列表

假设我们使用List数据结构保存某个明星/网红的粉丝,或者保存热点新闻的评论列表,因为粉丝数量巨大,热点新闻因为点击率、评论数会很多,这样List集合中存放的元素就会很多,可能导致value过大,进而产生Big Key问题。

三、Big Key的危害?

1、阻塞请求

Big Key对应的value较大,我们对其进行读写的时候,需要耗费较长的时间,这样就可能阻塞后续的请求处理。Redis的核心线程是单线程,单线程中请求任务的处理是串行的,前面的任务完不成,后面的任务就处理不了。

2、内存增大

读取Big Key耗费的内存比正常Key会有所增大,如果不断变大,可能会引发OOM(内存溢出),或达到redis的最大内存maxmemory设置值引发写阻塞或重要Key被逐出。

3、阻塞网络

读取单value较大时会占用服务器网卡较多带宽,自身变慢的同时可能会影响该服务器上的其他Redis实例或者应用。

4、影响主从同步、主从切换

删除一个大Key造成主库较长时间的阻塞并引发同步中断或主从切换。

四、如何识别Big Key?

1、使用redis自带的命令识别

例如可以使用Redis官方客户端redis-cli加上--bigkeys参数,可以找到某个实例5种数据类型(String、hash、list、set、zset)的最大key。
    优点是可以在线扫描,不阻塞服务;缺点是信息较少,内容不够精确。

2、使用debug object key命令

根据传入的对象(Key的名称)来对Key进行分析并返回大量数据,其中serializedlength的值为该Key的序列化长度,需要注意的是,Key的序列化长度并不等同于它在内存空间中的真实长度,此外,debug object属于调试命令,运行代价较大,并且在其运行时,进入Redis的其余请求将会被阻塞直到其执行完毕。并且每次只能查找单个key的信息,官方不推荐使用。

3、redis-rdb-tools开源工具

这种方式是在redis实例上执行bgsave,bgsave会触发redis的快照备份,生成rdb持久化文件,然后对dump出来的rdb文件进行分析,找到其中的大key。

GitHub地址:https://github.com/sripathikrishnan/redis-rdb-tools

优点在于获取的key信息详细、可选参数多、支持定制化需求,结果信息可选择json或csv格式,后续处理方便,其缺点是需要离线操作,获取结果时间较长。

五、如何解决Big Key问题?

要解决Big Key问题,无非就是减小key对应的value值的大小,也就是对于String数据结构的话,减少存储的字符串的长度;对于List、Hash、Set、ZSet数据结构则是减少集合中元素的个数。

1、对大Key进行拆分

将一个Big Key拆分为多个key-value这样的小Key,并确保每个key的成员数量或者大小在合理范围内,然后再进行存储,通过get不同的key或者使用mget批量获取。

2、对大Key进行清理

对Redis中的大Key进行清理,从Redis中删除此类数据。Redis自4.0起提供了UNLINK命令,该命令能够以非阻塞的方式缓慢逐步的清理传入的Key,通过UNLINK,你可以安全的删除大Key甚至特大Key。

3、监控Redis的内存、网络带宽、超时等指标

通过监控系统并设置合理的Redis内存报警阈值来提醒我们此时可能有大Key正在产生,如:Redis内存使用率超过70%,Redis内存1小时内增长率超过20%等。

4、定期清理失效数据

如果某个Key有业务不断以增量方式写入大量的数据,并且忽略了其时效性,这样会导致大量的失效数据堆积。可以通过定时任务的方式,对失效数据进行清理。

5、压缩value

使用序列化、压缩算法将key的大小控制在合理范围内,但是需要注意序列化、反序列化都会带来一定的消耗。如果压缩后,value还是很大,那么可以进一步对key进行拆分。

补充知识:key设计

(1)【建议】: 可读性和可管理性

以业务名(或数据库名)为前缀(防止key冲突),用冒号分隔,比如业务名:表名:id
o2o:order:1

(2)【建议】:简洁性

保证语义的前提下,控制key的长度,当key较多时,内存占用也不容忽视,例如:
user:{uid}:friends:messages:{mid} 简化为 u:{uid}m:{mid}

(3)【强制】:不要包含特殊字符

反例:包含空格、换行、单双引号以及其他转义字符

总结

到此这篇关于Redis中什么是Big Key(大key)问题的文章就介绍到这了,更多相关Redis Big Key问题解决内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • redis的bigkey扫描脚本深入介绍

    前言 众所周知,redis里面的大key存在是非常危险的一件事情.因为最近的工作转移到中间件相关的工作,因此关注了一下bigkey的扫描方法.首先介绍一下阿里云提供的扫描脚本: 具体可见:https://yq.aliyun.com/articles/117042?t=t1 我对这个脚本进行了一个压力测试,在redis的内存为15G,key的数量为2KW,ops为40K到80K之间,在这种情况下,阿里云的脚本完全不能跑成功(估计跑出来的时间以天为单位),主要原因是每确认一个key的情况,就需要与r

  • Redis大key多key拆分实现方法解析

    背景 业务场景中经常会有各种大key多key的情况, 比如: 1:单个简单的key存储的value很大 2:hash, set,zset,list 中存储过多的元素(以万为单位) 3:一个集群存储了上亿的key,Key 本身过多也带来了更多的空间占用 (如无意外,文章中所提及的hash,set等数据结构均指redis中的数据结构 ) 由于redis是单线程运行的,如果一次操作的value很大会对整个redis的响应时间造成负面影响,所以,业务上能拆则拆,下面举几个典型的分拆方案. 一.单个简单的

  • Redis中什么是Big Key(大key)问题?如何解决Big Key问题?

    目录 一.什么是Big Key? 二.Big Key产生的场景? 三.Big Key的危害? 四.如何识别Big Key? 五.如何解决Big Key问题? 补充知识:key设计 总结 一.什么是Big Key? 通俗易懂的讲,Big Key就是某个key对应的value很大,占用的redis空间很大,本质上是大value问题.key往往是程序可以自行设置的,value往往不受程序控制,因此可能导致value很大. redis中这些Big Key对应的value值很大,在序列化/反序列化过程中花

  • Redis什么是热Key问题以及如何解决热Key问题

    目录 一.什么是热Key? 二.热Key产生的原因? 三.热点Key的危害? 四.如何识别热点Key? 五.如何解决热Key问题? 一.什么是热Key? 在Redis中,我们把访问频率高的Key,称为热Key. 比如突然又几十万的请求去访问redis中某个特定的Key,那么这样会造成redis服务器短时间流量过于集中,很可能导致redis的服务器宕机. 那么接下来对这个Key的请求,都会直接请求到我们的后端数据库中,数据库性能本来就不高,这样就可能直接压垮数据库,进而导致后端服务不可用. 二.热

  • 面试分析分布式架构Redis热点key大Value解决方案

    目录 引言 1.面试官:你在项目中有没有遇到Redis热点数据问题,一般都是什么原因引起的? 2.面试官:真实项目中,那热点数据问题你是如何准确定位的呢? 3.如何解决热点数据问题 4.面试官:关于Redis最后一个问题,Redis支持丰富的数据类型,那么这些数据类型存储的大Value如何解决,线上有遇到这种情况吗? 总结 引言 关于 Redis 热点数据 & 大 key 大 value 问题也是容易被问的高阶问题,不如一次痛快点说完,让面试官无话可说,个人工作经验中,热点数据问题在工作中相比雪

  • redis中热key问题该如何解决

    引言 讲了几天的数据库系列的文章,大家一定看烦了,其实还没讲完...(以下省略一万字). 今天我们换换口味,来写redis方面的内容,谈谈热key问题如何解决. 其实热key问题说来也很简单,就是瞬间有几十万的请求去访问redis上某个固定的key,从而压垮缓存服务的情情况. 其实生活中也是有不少这样的例子.比如XX明星结婚.那么关于XX明星的Key就会瞬间增大,就会出现热数据问题. ps: hot key和big key问题,大家一定要有所了解. 本文预计分为如下几个部分 热key问题 如何发

  • redis中key的设置方法步骤

    Redis SET命令用于设置给定key的值.如果key已经存储其他值,SET就覆写旧值,且无视类型. redis SET命令基本语法如下: redis 127.0.0.1:6379> SET KEY_NAME VALUE 返回值: 在Redis2.6.12以前版本,SET命令总是返回OK . 从Redis2.6.12版本开始,SET在设置操作成功完成时,才返回OK 实例: 在redis中创建一个key并设置值. # 对不存在的键进行设置 redis 127.0.0.1:6379> SET k

  • 详解Redis中key的命名规范和值的命名规范

    数据库中得热点数据key命名惯例 表名:主键名:主键值:字段名 例如 user:id:0001:name 例如 user:id:0002:name 例如 order:id:s2002:price 上面的key对应的值则可以是 存放的方式 key value 优点 单独的key:value形式 order:id:s2002:price 2000 方便简单的操作,例如incr自增或自减 json格式 user:id:0001 {id:0001,name:"张三"} 方便一次性存和取数据,但

  • SpringBoot如何监控Redis中某个Key的变化(自定义监听器)

    目录 SpringBoot 监控Redis中某个Key的变化 1.声明 2.基本理念 3.实现和创建监听 4.基本demo的其他配置 5.基本测试 6.小结一下 SpringBoot自定义监听器 原理 示例 SpringBoot 监控Redis中某个Key的变化 1.声明 当前内容主要为本人学习和基本测试,主要为监控redis中的某个key的变化(感觉网上的都不好,所以自己看Spring源码直接写一个监听器) 个人参考: Redis官方文档 Spring-data-Redis源码 2.基本理念

  • Redis中5种数据结构的使用场景介绍

    一.redis 数据结构使用场景 原来看过 redisbook 这本书,对 redis 的基本功能都已经熟悉了,从上周开始看 redis 的源码.目前目标是吃透 redis 的数据结构.我们都知道,在 redis 中一共有5种数据结构,那每种数据结构的使用场景都是什么呢? String--字符串 Hash--字典 List--列表 Set--集合 Sorted Set--有序集合 下面我们就来简单说明一下它们各自的使用场景: 1. String--字符串 String 数据结构是简单的 key-

  • php操作redis中的hash和zset类型数据的方法和代码例子

    前面一篇博客主要是string类型,list类型和set类型,下面hash类型和zset类型 1,hset 描述:将哈希表key中的域field的值设为value.如果key不存在,一个新的哈希表被创建并进行HSET操作.如果域field已经存在于哈希表中,旧值将被覆盖. 参数:key field value 返回值:如果field是哈希表中的一个新建域,并且值设置成功,返回1.如果哈希表中域field已经存在且旧值已被新值覆盖,返回0. 2,hsetnx 描述:将哈希表key中的域field的

  • Redis中主键失效的原理及实现机制剖析

    作为一种定期清理无效数据的重要机制,主键失效存在于大多数缓存系统中,Redis 也不例外.在 Redis 提供的诸多命令中,EXPIRE.EXPIREAT.PEXPIRE.PEXPIREAT 以及 SETEX 和 PSETEX 均可以用来设置一条 Key-Value 对的失效时间,而一条 Key-Value 对一旦被关联了失效时间就会在到期后自动删除(或者说变得无法访问更为准确).可以说,主键失效这个概念还是比较容易理解的,但是在具体实现到 Redis 中又是如何呢?最近本博主就对 Redis

随机推荐