您现在的位置: 首页 > 网站导航收录 > 百科知识百科知识

(key什么意思)-key的多种意思

数据,阿里,命令(key什么意思)-key的多种意思

发布时间：2016-12-08加入收藏来源：互联网点击：

一 前言

在Redis的使用过程中，我们经常会遇到BigKey（下文将其称为“大key”）及HotKey（下文将其称为“热key”）。大Key与热Key如果未能及时发现并进行处理，很可能会使服务性能下降、用户体验变差，甚至引发大面积故障。

二 大Key与热Key的定义

我们经常能够在公司内部的Redis开发使用规范手册，或网络中大量的Redis最佳实践文章里看到有关大Key、热Key的定义，然而这些资料中的大Key热Key判定标准却不尽相同，但可以明确的是，它们的判定维度是一致的：大Key通常都会以数据大小与成员数量来判定，而热Key则以其接收到的请求频率、数量来判定。

1 什么是大Key

通常我们会将含有较大数据或含有大量成员、列表数的Key称之为大Key，下面我们将用几个实际的例子对大Key的特征进行描述：

一个STRING类型的Key，它的值为5MB（数据过大）一个LIST类型的Key，它的列表数量为20000个（列表数量过多）一个ZSET类型的Key，它的成员数量为10000个（成员数量过多）一个HASH格式的Key，它的成员数量虽然只有1000个但这些成员的value总大小为100MB（成员体积过大）

需要注意的是，在以上的例子中，为了方便理解，我们对大Key的数据、成员、列表数给出了具体的数字。为了避免误导，在实际业务中，大Key的判定仍然需要根据Redis的实际使用场景、业务场景来进行综合判断。

2 什么是热Key

在某个Key接收到的访问次数、显著高于其它Key时，我们可以将其称之为热Key，常见的热Key如：

某Redis实例的每秒总访问量为10000，而其中一个Key的每秒访问量达到了7000（访问次数显著高于其它Key）对一个拥有上千个成员且总大小为1MB的HASH Key每秒发送大量的HGETALL（带宽占用显著高于其它Key）对一个拥有数万个成员的ZSET Key每秒发送大量的ZRANGE（CPU时间占用显著高于其它Key）

三 大Key与热Key带来的问题

在Redis的使用中，大Key及热Key会给Redis带来各种各样的问题，而最常见的问题为性能下降、访问超时、数据不均衡等。

1 大Key带来的常见问题

Client发现Redis变慢；Redis内存不断变大引发OOM，或达到maxmemory设置值引发写阻塞或重要Key被逐出；Redis Cluster中的某个node内存远超其余node，但因Redis Cluster的数据迁移最小粒度为Key而无法将node上的内存均衡化；大Key上的读请求使Redis占用服务器全部带宽，自身变慢的同时影响到该服务器上的其它服务；删除一个大Key造成主库较长时间的阻塞并引发同步中断或主从切换；

2 热Key带来的常见问题

热Key占用大量的Redis CPU时间使其性能变差并影响其它请求；Redis Cluster中各node流量不均衡造成Redis Cluster的分布式优势无法被Client利用，一个分片负载很高而其它分片十分空闲从而产生读/写热点问题；在抢购、秒杀活动中，由于商品对应库存Key的请求量过大超出Redis处理能力造成超卖；热Key的请求压力数量超出Redis的承受能力造成缓存击穿，此时大量强求将直接指向后端存储将其打挂并影响到其它业务；

四 大Key与热Key的常见产生原因

业务规划不足、Redis不正确的使用、无效数据的堆积、访问突增等都会产生大Key与热Key，如：

将Redis用在并不适合其能力的场景，造成Key的value过大，如使用String类型的Key存放大体积二进制文件型数据（大Key）；业务上线前规划设计考虑不足没有对Key中的成员进行合理的拆分，造成个别Key中的成员数量过多（大Key）；没有对无效数据进行定期清理，造成如HASH类型Key中的成员持续不断的增加（大Key）；预期外的访问量陡增，如突然出现的爆款商品、访问量暴涨的热点新闻、直播间某大主播搞活动带来的大量刷屏点赞、游戏中某区域发生多个工会间的战斗涉及大量玩家等（热Key）；使用LIST类型Key的业务消费侧代码故障，造成对应Key的成员只增不减（大Key）；

五 找出Redis中的大Key与热Key

大Key与热Key的分析并不困难，我们有多种途径和手段来对Redis中的Key进行分析并找出其中的“问题”Key，如Redis的内置功能、开源工具、阿里云Redis控制台中的Key分析功能等。

1 使用Redis内置功能发现大Key及热Key

Redis内置的一些命令、工具都可以帮助我们来发现这些问题Key。当你对Redis的大Key热Key已有明确的分析目标时，可以通过如下命令对对应Key进行分析。

通过Redis内置命令对目标Key进行分析

可能你会选择使用debug object命令对Key进行分析。该命令能够根据传入的对象（Key的名称）来对Key进行分析并返回大量数据，其中serializedlength的值为该Key的序列化长度，你可能会选择通过该数据来判断对应Key是否符合你的大Key判定标准。

需要注意的是，Key的序列化长度并不等同于它在内存空间中的真实长度，此外，debug object属于调试命令，运行代价较大，并且在其运行时，进入Redis的其余请求将会被阻塞直到其执行完毕。而该命令的运行的时间长短取决于传入对象（Key名）序列化长度的大小，因此，在线上环境中并不推荐使用该命令来分析大Key，这可能引发故障。

Redis自4.0起提供了MEMORY USAGE命令来帮助分析Key的内存占用，相对debug object它的执行代价更低，但由于其时间复杂度为O(N)因此在分析大Key时仍有阻塞风险。

我们建议通过风险更低方式来对Key进行分析，Redis对于不同的数据结构提供了不同的命令来返回其长度或成员数量，如下表：

通过以上Redis内置命令我们可以方便且安全的对Key进行分析而不会影响线上服务，但由于它们返回的结果非Key的真实内存占用数据，因此不够精确，仅可作为参考。

通过Redis官方客户端redis-cli的bigkeys参数发现大Key

如果你并无明确的目标Key用于分析，而是希望通过工具找出整个Redis实例中的大Key，此时redis-cli的bigkeys参数能够方便的帮你实现这个目标。

Redis提供了bigkeys参数能够使redis-cli以遍历的方式分析整个Redis实例中的所有Key并汇总以报告的方式返回结果。该方案的优势在于方便及安全，而缺点也非常明显：分析结果不可定制化。

bigkeys仅能分别输出Redis六种数据结构中的最大Key，如果你想只分析STRING类型或是找出全部成员数量超过10的HASH Key，那么bigkeys在此类需求场景下将无能为力。

GitHub上有大量的开源项目能够实现bigkeys的加强版使结果能够按照配置定制化输出，另外你可也以动手使用SCAN TYPE并配合上文表格中的命令自己实现一个Redis实例级的大Key分析工具。

 1/3    1 2 3 下一页 尾页