如何找出并优化大Key与热Key_云数据库 Tair（兼容 Redis®）(Tair)-阿里云帮助中心

Big keys（大Key）与Hot keys（热Key）可能导致服务性能下降、用户体验变差，甚至引发系统故障。本文介绍如何快速找出和优化大Key与热Key，分析其产生原因及可能引发的问题，并提供预防措施以降低对业务的影响。

快速找出大Key和热Key

阿里云自研工具

Tair和Redis在控制台提供了Top Key统计和离线全量Key分析功能帮助您快速找出大Key与热Key。

方法	使用限制	说明

方法

使用限制

说明

Top Key统计（推荐）

仅Redis开源版5.0及以上版本和Tair（企业版）内存型、持久内存型支持该功能。

实时显示每个分片中各数据类型前三的大Key和热Key信息。
支持查看4天内大Key和热Key的历史信息。
对线上服务几乎无影响。

离线全量Key分析

单副本实例类型或磁盘型实例不支持该功能。

对RDB备份文件进行定制化的分析，得出Key在内存中的占用和分布、Key过期时间等信息。
对线上服务无影响。
时效性差，RDB文件较大时耗时较长。
无法分析热Key信息。

如果您的实例不能使用上述功能，请参考以下方法。

其他方法找出大Key和热Key

方法	优缺点	说明
通过redis-cli的bigkeys、memkeys和hotkeys参数查找大Key和热Key	优点：方便、快速、安全。缺点：分析结果不可定制化，准确性与时效性差；需要遍历实例当前所有Key，可能影响实例性能。	redis-cli的bigkeys、memkeys与hotkeys参数能获取Key的整体统计信息与每个数据类型中Top1的大Key或热Key。区别如下： bigkeys：统计大Key信息，集合或列表类型返回元素个数。 memkeys：统计大Key信息，返回所有数据类型所占内存大小。 hotkeys：统计热Key信息。支持的数据类型：STRING、LIST、HASH、SET、ZSET、STREAM。以bigkeys为例，命令示例为`redis-cli -h r-***************.redis.rds.aliyuncs.com -a <password> --bigkeys`。
通过内置命令对目标Key进行分析	优点：对线上服务影响小。缺点：返回的Key序列化长度并不等同于它在内存空间中的真实长度，因此不够准确，仅可作为参考。	对不同数据类型的目标Key，分别通过如下风险较低的命令进行分析，来判断目标Key是否符合大Key判定标准。 STRING类型：STRLEN命令，返回对应Key的value的字节数。 LIST类型：LLEN命令，返回对应Key的列表长度。 HASH类型：HLEN命令，返回对应Key的成员数量。 SET类型：SCARD命令，返回对应Key的成员数量。 ZSET类型：ZCARD命令，返回对应Key的成员数量。 STREAM类型：XLEN命令，返回对应Key的成员数量。说明 DEBUG OBJECT与MEMORY USAGE命令在执行时需占用较多资源，且时间复杂度为O(N)，有阻塞实例的风险，不建议使用。
通过业务层定位热Key	优点：可准确并及时地定位热Key。缺点：业务代码复杂度的增加，同时可能会降低一些性能。	通过在业务层增加相应的代码对实例的访问进行记录并异步汇总分析。
通过redis-rdb-tools工具以定制化方式找出大Key	优点：支持定制化分析，对线上服务无影响。缺点：时效性差，RDB文件较大时耗时较长。	Redis-rdb-tools是通过Python编写的开源工具，支持定制化分析RDB快照文件。下载RDB文件后，您可以根据业务需求分析实例中所有Key的内存占用情况，并支持灵活地查询。
通过MONITOR命令找出热Key	优点：方便、安全。缺点：会占用CPU、内存、网络资源，时效性与准确性较差。	MONITOR命令能够忠实地打印实例中的所有请求，包括时间信息、Client信息、命令以及Key信息。在发生紧急情况时，可以通过短暂执行MONITOR命令并将返回信息输入至文件，在关闭MONITOR命令后，对文件中请求进行归类分析，找出这段时间中的热Key。说明由于MONITOR命令对实例性能消耗较大，非特殊情况不推荐使用MONITOR命令。

优化大Key与热Key

类别	处理方法	说明

类别	处理方法	说明
大Key	对大Key进行压缩	建议在数据写入缓存前，通过序列化或压缩算法减少大Key的存储空间。若压缩后仍过大，可进一步拆分Key。
	对大Key进行拆分	例如将含有数万成员的一个HASH Key拆分为多个HASH Key，并确保每个Key的成员数量在合理范围。拆分大Key能有效避免数据倾斜。
	对大Key进行清理	将不适用数据存至其它存储，并在实例中删除此类数据。说明 Redis开源版4.0及之后版本：您可以通过UNLINK命令安全地删除大Key甚至特大Key，该命令通过异步方式清理 Key，避免阻塞主线程。 Redis开源版4.0之前的版本：建议先通过SCAN命令读取部分数据，然后进行删除，避免一次性删除大量key导致主线程阻塞。
	对过期数据进行定期清理	堆积大量过期数据会造成大Key的产生，例如在HASH数据类型中，由于忽略数据时效性，可能会以增量形式不断写入大量数据。可以通过定时任务的方式对失效数据进行清理。说明在清理HASH数据时，建议通过HSCAN命令配合HDEL命令对失效数据进行清理，避免清理大量数据造成实例阻塞。
热Key	在集群架构中对热Key进行复制	由于热Key作为整体存储在单一分片，无法通过迁移部分数据分散请求，导致单个数据分片的压力无法下降。此时，可以将对应热Key进行复制并迁移至其他数据分片，例如将热Key foo复制出3个内容完全一样的Key并命名为foo2、foo3、foo4，将这三个Key迁移到其他数据分片来解决单个数据分片的热Key压力。说明该方案的缺点是需修改代码维护多个副本，且多副本间的数据一致性难以保障（例如更新操作需同步所有副本）。建议将该方案作为临时解决方案，用于缓解棘手问题。
	开启读写分离功能	若热Key由读请求引起，您可以开启读写分离功能来降低每个数据分片的读请求负载，如果开启后读请求负载依旧很高，可通过增加只读节点数量进一步缓解读请求负载。说明读写分离同样存在缺点，在请求量极大的场景下，读写分离会产生不可避免的延迟，此时会出现读取到脏数据的问题。因此，在读、写压力都较大且对数据一致性要求很高的场景下，不推荐开启读写分离。
	开启QueryCache功能	开启该功能后，Tair和Redis会根据算法识别出热Key（通常热Key的QPS大于5,000），代理节点Proxy会缓存热Key的请求和查询结果（仅缓存点Key的查询结果，无需缓存整个Key）。当在缓存有效时间内收到相同的请求时，Proxy会直接返回结果至客户端，无需和后端的数据分片执行交互。更多信息，请参见通过Proxy Query Cache优化热点Key问题。

为什么会产生大Key和热Key?

Tair和Redis的最小数据分布粒度为Key。单个Key将存储在特定的数据分片中，且不会被拆分。业务规划不足、无效数据的堆积以及访问量的突增等因素，均会使实例产生大Key与热Key，如：

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

大Key和热Key可能会引发的问题

类别	说明

类别	说明
大Key	客户端执行命令的时长变慢。实例内存达到maxmemory上限时，可能导致操作阻塞、重要Key被逐出，甚至内存溢出（OOM）。集群架构下，某个数据分片的内存使用率远超其他数据分片，无法使数据分片的内存资源达到均衡。对大Key执行读请求，会使实例的带宽使用率被占满，导致自身服务变慢，同时易波及相关的服务。对大Key执行删除操作，易造成主库较长时间的阻塞，进而可能引发同步中断或主从切换。
热Key	占用大量的CPU资源，同时可能增加网络带宽的使用，进而影响其他请求并导致整体性能降低。集群架构下，产生访问倾斜，即某个数据分片被大量访问，而其他数据分片处于空闲状态，可能引起该数据分片的连接数被耗尽，新的连接建立请求被拒绝等问题。在抢购或秒杀场景下，可能因商品对应库存Key的请求量过大，超出实例处理能力造成超卖。热Key的请求压力数量超出实例的承受能力，容易造成缓存击穿，即大量请求将被直接指向后端的存储层，导致存储访问量激增甚至宕机，从而影响其他业务。

如何预防大Key和热Key影响业务

方法	说明

方法	说明
配置监控报警	您可以通过监控系统设置合理的CPU、内存、连接数使用率等报警阈值进行报警，例如内存使用率超过70%、内存在1小时内增长率超过20%等。出现报警时，根据上文内容找到并优化大Key和热Key，在其发展到影响业务之前解决。更多信息，请参见报警设置。
使用Tair（企业版）避开失效数据的清理工作	针对hash类型的大key场景，Tair（企业版）提供了增强型数据结构 TairHash。它支持为每个 field 设置过期时间和版本，突破了 Redis Hash 仅能为整个 Key 设置过期时间的限制。同时，TairHash 使用高效的 Active Expire 算法，在几乎不影响响应时间的情况下完成field的过期判断与删除操作。通过合理使用 TairHash，可以显著减少运维负担、简化业务代码复杂度，并有效应对大 Key 和热 Key 带来的问题。