Redis之大key热点key的问题及处理
作者：信仰_273993243
大key（Large Key）通常指的是一个key对应的value很大，例如一个string类型的value大小达到10KB，或者一个list、hash、set、zset等集合类型的元素数量过多（比如超过10000个）。
大key的危害包括：
- 网络阻塞：读取大key会消耗大量带宽，可能导致网络阻塞。
- 内存占用高：导致内存使用不均，可能引发内存不足。
- 阻塞操作：对于Redis，删除大key可能导致服务阻塞（因为Redis是单线程）。
使用Redis自带的命令：redis-cli --bigkeys、有一些开源工具可以分析RDB文件，例如redis-rdb-tools，通过分析RDB文件来找出大key。
- 拆分大key：对于string类型的大key，可以尝试将value拆分成多个部分、对于集合类型，可以按照某种规则（例如哈希取模）将一个大集合拆分成多个小集合
- 删除大key：删除大key时，要避免阻塞Redis。对于集合类型，可以使用渐进式删除
- 设置过期时间：对于有时效性的大key，可以设置过期时间，让其自动过期
热点key（Hot Key）指的是被频繁访问的key。热点key的危害包括：
- 流量集中：可能导致某个Redis实例的流量过大，成为瓶颈（尤其是在集群模式下）。
- 服务不可用：如果热点key的访问量超过Redis的处理能力，可能导致服务崩溃。
使用Redis自带的命令：redis-cli --hotkeys
- 使用本地缓存
- 拆分热点key：如果热点key是一个集合，可以拆分成多个key，分散到不同的节点、对于只读的热点key，可以复制多份，比如key_1, key_2，后面追加随机数。
- 使用读写分离：通过Redis的读写分离，将读请求分散到多个从节点，降低主节点的压力
- 使用Redis集群：将热点key分散到不同的Redis实例上，避免单个实例成为瓶颈。
一、big key
大Key通常都会以数据大小与成员数量来判定：
- 一个STRING类型的Key，它的值为5MB（数据过大）
- 一个LIST类型的Key，它的列表数量为20000个（列表数量过多）
- 一个ZSET类型的Key，它的成员数量为10000个（成员数量过多）
- 一个HASH格式的Key，它的成员数量虽然只有1000个但这些成员的value总大小为100MB（成员体积过大）
1、大key引发的问题
- 存储引发OOM：Redis内存不断变大引发OOM
- 存储：分布不均衡：Redis Cluster中的某个node内存远超其余node，无法将node上的内存均衡化
- 查询占带宽：大Key上的读请求使Redis占用服务器全部带宽
- 删除时阻塞：删除一个大Key造成主库较长时间的阻塞
2、找出大key
- 通过Redis官方客户端redis-cli的big keys参数发现大Key
- Memory Usage：命令来帮助分析Key的内存占用，相对debug object命令，它的执行代价更低仍有阻塞风险。
- Redis对于不同的数据结构提供了不同的命令来返回其长度或成员数量，如下图
- redis-rdb-tools工具以定制化方式找出大Key
3、解决方案
- 存-对大Key进行拆分：HASH Key拆分为多个HASH Key，确保每个Key的成员数量在合理范围
- 删-对大Key进行清理：Redis自4.0起提供了unlink命令，该命令能够以非阻塞的方式缓慢逐步的清理传入的Key，通过UNLINK，你可以安全的删除大Key甚至特大Key。
- 监控Redis的内存水位：通过[监控系统]，比如普罗米修斯，并设置合理的Redis内存报警阈值来提醒我们此时可能有大Key正在产生，如：Redis内存使用率超过70%，Redis内存1小时内增长率超过20%等。
二、hotkey
热Key则以其接收到的请求频率，请求次数来判定，比如：Redis实例的每秒总访问量为10000，而其中一个Key的每秒访问量达到了7000
1、带来的问题
- 查询-占用CPU：热Key占用大量的Redis CPU时间使其性能变差
- 查询-节点请求不均衡：Redis Cluster中Node流量不均衡造成Redis Cluster的分布式优势无法被Client利用
2、找出HotKey
- 通过Redis官方客户端redis-cli的hot keys参数发现热Key
- 通过业务层定位热Key
- 使用monitor命令：在紧急情况时找出热Key，能够打印真实的请求，缺点就是Redis的CPU、内存、网络资源均有一定的占用
3、处理方式
- 存储-多节点复制：在Redis Cluster结构中对热Key进行复制，因为分布的时候是通过Hash key来得到节点，所以通过修改Key的值，来改变value的分布。
- 查询-使用读写分离架构：在使用读写分离架构时可以通过不断的【增加从节点】来降低每个Redis实例中的读请求压力
三、Tair
大key
- 删-使用阿里云的Tair(Redis企业版)服务避开失效数据的清理工作
hotkey
- 使用阿里云Tair的QueryCache特性，其实就是类似于二级缓存，把缓存放在redis proxy层。
1、介绍
- Tair（Tair缓存框架）是阿里巴巴开发的分布式缓存系统，它并不是直接基于Redis实现的。相反，Tair是一个独立的分布式缓存解决方案，具有自己的架构和特性。
- 虽然Tair和Redis都是分布式缓存系统，但它们是由不同的团队开发，采用了不同的设计和实现。Tair在设计上考虑了阿里巴巴业务的特点和需求，提供了一些针对大规模分布式环境的优化和功能。
2、过期算法：
TairHash使用高效的【Active Expire】算法，实现了在对响应时间几乎无影响的前提下，高效完成对field过期判断和删除的功能。此类高级功能的合理使用能够解放大量Redis的运维、故障处理工作并降低业务的代码复杂度，让运维将精力投入到其它更有价值的工作中，让研发有更多的时间来写更有价值的代码。
3、QueryCache是阿里云Tair（Redis企业版）服务的企业级特性之一
Tair QueryCache原理
- 阿里云数据库Redis会根据高效的排序和统计算法识别出实例中存在的热点Key，开启该功能后，Proxy点会根据设定的规则【缓存】热点Key的请求和查询结果（仅缓存热点Key的查询结果，无需缓存整个Key），当在缓存有效时间内收到相同的请求时【Proxy会直接返回结果至客户端】，无需和后端的Redis分片执行交互。
- 在提升读取速度的同时，降低了热点Key对数据分片的性能影响，避免发生请求倾斜。
至此，来自客户端的同样的请求无需再与Proxy后端的Redis进行交互而由Proxy直接返回数据，指向热Key的请求由一个Redis节点承担转为多个Proxy共同承担，能够大幅度降低Redis节点的热Key压力，同时Tair的QueryCache功能还提供了大量的命令来方便用户查看、管理，如通过querycache keys命令查看所有被缓存热Key，通过querycache listall获取所有已缓存的所有命令等。
Tair QueryCache智能化的热Key判定与缓存联动功同样能够降低运维及研发的工作负担。与传统的Redis同步中间件相比，阿里云Redis全球分布式缓存具有高可靠性、高吞吐低延迟、同步正确性高等特点。
总结
以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。