大Key和热Key的定义
名词 | 解释 |
大Key | 通常以Key的大小和Key中成员的数量来综合判定,例如: Key本身的数据量过大:一个String类型的Key,它的值为5 MB。 Key中的成员数过多:一个ZSET类型的Key,它的成员数量为10,000个。 Key中成员的数据量过大:一个Hash类型的Key,它的成员数量虽然只有2,000个但这些成员的Value(值)总大小为100 MB。
|
热Key | 通常以其接收到的Key被请求频率来判定,例如: QPS集中在特定的Key:Tair实例的总QPS(每秒查询率)为10,000,而其中一个Key的每秒访问量达到了7,000。 带宽使用率集中在特定的Key:对一个拥有上千个成员且总大小为1 MB的HASH Key每秒发送大量的HGETALL操作请求。 CPU使用时间占比集中在特定的Key:对一个拥有数万个成员的Key(ZSET类型)每秒发送大量的ZRANGE操作请求。
|
说明 上述例子中的具体数值仅供参考,在实际业务中,您需要根据实例的实际业务场景进行综合判断。
大Key和热Key引发的问题
类别 | 说明 |
大Key | 客户端执行命令的时长变慢。 Tair内存达到maxmemory参数定义的上限引发操作阻塞或重要的Key被逐出,甚至引发内存溢出(Out Of Memory)。 集群架构下,某个数据分片的内存使用率远超其他数据分片,无法使数据分片的内存资源达到均衡。 对大Key执行读请求,会使Tair实例的带宽使用率被占满,导致自身服务变慢,同时易波及相关的服务。 对大Key执行删除操作,易造成主库较长时间的阻塞,进而可能引发同步中断或主从切换。
|
热Key | 占用大量的CPU资源,影响其他请求并导致整体性能降低。 集群架构下,产生访问倾斜,即某个数据分片被大量访问,而其他数据分片处于空闲状态,可能引起该数据分片的连接数被耗尽,新的连接建立请求被拒绝等问题。 在抢购或秒杀场景下,可能因商品对应库存Key的请求量过大,超出Tair处理能力造成超卖。 热Key的请求压力数量超出Tair的承受能力易造成缓存击穿,即大量请求将被直接指向后端的存储层,导致存储访问量激增甚至宕机,从而影响其他业务。
|
大Key和热Key产生的原因
未正确使用Tair、业务规划不足、无效数据的堆积、访问量突增等都会产生大Key与热Key,如:
大key
在不适用的场景下使用Tair,易造成Key的value过大,如使用String类型的Key存放大体积二进制文件型数据;
业务上线前规划设计不足,没有对Key中的成员进行合理的拆分,造成个别Key中的成员数量过多;
未定期清理无效数据,造成如HASH类型Key中的成员持续不断地增加;
使用LIST类型Key的业务消费侧发生代码故障,造成对应Key的成员只增不减。
热key
快速找出大Key和热Key
Tair提供多种方案帮助您轻松找出大Key与热Key。
方法 | 优缺点 | 说明 |
实时Top Key统计(推荐) | | 可实时展示实例中的大Key和热Key信息,同时支持查看4天内大Key和热Key的历史信息。该功能可帮助您掌握Key在内存中的占用、Key的访问频次等信息,溯源分析问题,为您的优化操作提供数据支持。 |
离线全量Key分析 | | 对Tair的RDB备份文件进行定制化的分析,帮助您发现实例中的大Key,掌握Key在内存中的占用和分布、Key过期时间等信息,为您的优化操作提供数据支持,帮助您避免因Key倾斜引发的内存不足、性能下降等问题。 |
通过redis-cli的bigkeys和hotkeys参数查找大Key和热Key | 优点:方便、快速、安全。 缺点:分析结果不可定制化,准确性与时效性差。
| redis-cli提供了bigkeys与hotkeys参数能够以遍历的方式分析Tair实例中的所有Key,并返回Key的整体统计信息与每个数据类型中Top1的大Key。 以bigkeys为例,其仅能分析并输入六种数据类型(STRING、LIST、HASH、SET、ZSET、STREAM),命令示例为redis-cli -h r-***************.redis.rds.aliyuncs.com -a <password> --bigkeys 。
说明 若您只需要分析STRING类型的大key或是找出成员数量超过10个的HASH Key,则bigkeys参数无法直接实现该类需求。 |
通过Tair内置命令对目标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),有阻塞Tair实例的风险,不建议使用。 |
通过业务层定位热Key | | 通过在业务层增加相应的代码对Tair的访问进行记录并异步汇总分析。 |
通过redis-rdb-tools工具以定制化方式找出大Key | 优点:支持定制化分析,对线上服务无影响。 缺点:时效性差,RDB文件较大时耗时较长。
| Redis-rdb-tools是通过Python编写,支持定制化分析RDB快照文件的开源工具。您可以根据您的精细化需求,全面地分析Tair实例中所有Key的内存占用情况,同时也支持灵活地分析查询。 |
通过MONITOR命令找出热Key | | Tair的MONITOR命令能够忠实地打印Tair中的所有请求,包括时间信息、Client信息、命令以及Key信息。 在发生紧急情况时,可以通过短暂执行MONITOR命令并将返回信息输入至文件,在关闭MONITOR命令后,对文件中请求进行归类分析,找出这段时间中的热Key。
说明 由于MONITOR命令对Tair实例性能消耗较大,非特殊情况不推荐使用MONITOR命令。 |
优化大Key与热Key
类别 | 处理方法 |
大Key | 对大Key进行拆分 例如将含有数万成员的一个HASH Key拆分为多个HASH Key,并确保每个Key的成员数量在合理范围。在集群架构中,拆分大Key能对数据分片间的内存平衡起到显著作用。 对大Key进行清理 将不适用Tair能力的数据存至其它存储,并在Tair中删除此类数据。 监控Tair的内存水位 您可以通过监控系统设置合理的Tair内存报警阈值进行提醒,例如Tair内存使用率超过70%、Tair的内存在1小时内增长率超过20%等。通过此类监控手段,可以提前规避许多问题,例如LIST数据类型的消费程序故障造成对应Key的列表数量持续增长,将告警转变为预警从而避免故障的发生,更多信息,请参见报警设置。 对过期数据进行定期清理 堆积大量过期数据会造成大Key的产生,例如在HASH数据类型中以增量的形式不断写入大量数据而忽略了数据的时效性。可以通过定时任务的方式对失效数据进行清理。
说明 在清理HASH数据时,建议通过HSCAN命令配合HDEL命令对失效数据进行清理,避免清理大量数据造成Tair阻塞。 使用阿里云的Tair(企业版)避开失效数据的清理工作 若HASH Key过多,存在大量的成员失效需要被清理的问题,又由于大量Key与大量失效数据叠加,无法通过定时任务对无效数据进行及时地清理,您可以通过阿里云Tair服务高效地解决此类问题。 Tair具备Redis开源版所有特性(包括Redis开源版的高性能特点),同时提供了大量额外的高级功能。 TairHash是一种可为field设置过期时间和版本的Hash数据类型,它不但和Redis Hash一样支持丰富的数据接口和高处理性能,还改变了Hash只能为Key设置过期时间的限制,可以为field设置过期时间和版本。这极大地提高了Hash数据类型的灵活性,简化了很多场景下的业务开发工作。同时,TairHash使用高效的Active Expire算法,实现了在对响应时间几乎无影响的前提下,高效完成对field过期判断和删除的功能。 此类高级功能的合理使用能够解放大量Redis开源版的运维、故障处理工作并降低业务的代码复杂度,更多信息,请参见exHash。
|
热Key | 在集群架构中对热Key进行复制 在集群架构中,由于热Key的迁移粒度问题,无法将请求分散至其他数据分片,导致单个数据分片的压力无法下降。此时,可以将对应热Key进行复制并迁移至其他数据分片,例如将热Key foo复制出3个内容完全一样的Key并名为foo2、foo3、foo4,将这三个Key迁移到其他数据分片来解决单个数据分片的热Key压力。
说明 该方案的缺点在于需要联动修改代码,同时带来了数据一致性的挑战(由原来更新一个Key演变为需要更新多个Key),仅建议该方案用来解决临时棘手的问题。 使用读写分离架构 如果热Key的产生来自于读请求,您可以将实例改造成读写分离架构来降低每个数据分片的读请求压力,甚至可以不断地增加从节点。但是读写分离架构在增加业务代码复杂度的同时,也会增加集群架构复杂度。不仅要为多个从节点提供转发层(如Proxy,LVS等)来实现负载均衡,还要考虑从节点数量显著增加后带来故障率增加的问题。集群架构变更会为监控、运维、故障处理带来了更大的挑战。 然而,阿里云Tair服务以开箱即用的方式提供服务。在业务发生变化时,您仅需通过变配的方式调整实例架构来轻松应对,例如将主从架构转变为读写分离架构、将读写分构架构转变为集群架构,以及将Redis开源版转变为支持大量高级特性的Tair(企业版)等,更多信息,请参见变更实例配置。
说明 读写分离架构同样存在缺点,在请求量极大的场景下,读写分离架构会产生不可避免的延迟,此时会有读取到脏数据的问题。因此,在读、写压力都较大且对数据一致性要求很高的场景下,读写分离架构并不是最优方案。 使用阿里云Tair的QueryCache特性 云数据库 Tair(兼容 Redis)会根据高效的排序和统计算法识别出实例中存在的热点Key(通常热点Key的QPS大于5,000),开启该功能后,代理节点Proxy会根据设定的规则缓存热点Key的请求和查询结果(仅缓存热点Key的查询结果,无需缓存整个Key)。当在缓存有效时间内收到相同的请求时,Proxy会直接返回结果至客户端,无需和后端的数据分片执行交互。如果热点Key的查询结果发生改变,缓存不会更新。 开通该功能后,来自客户端的同样请求无需再与Proxy后端数据节点进行交互而是由Proxy直接返回数据,指向热Key的请求由一个数据节点承担转为多个Proxy共同承担,能够大幅度降低数据节点的热Key压力。同时Tair的QueryCache功能还提供了大量的命令来方便您查看、管理代理查询缓存的情况,例如通过querycache keys命令查看所有被缓存热Key,通过querycache listall命令获取所有已缓存的所有命令等。更多信息,请参见通过Proxy Query Cache优化热点Key问题。
|