Redis的热key以及Big(大)key是什么?如何解决Redis的热key以及Big(大)key问题?
一、先讲讲什么是redis的热key问题
在Redis中,我们把访问频率高的Key,称为热Key。比如突然有几十万的请求去访问redis中某个特定的Key,那么这样会造成redis服务器短时间流量过于集中,很可能导致redis的服务器宕机。那么接下来对这个Key的请求,都会直接请求到我们的后端数据库中,数据库性能本来就不高,这样就可能直接压垮数据库,进而导致后端服务不可用。
1.1 热Key产生的原因
1、用户消费的数据远大于生产的数据,如商品秒杀、热点新闻、热点评论等读多写少的场景。
双十一秒杀商品,短时间内某个爆款商品可能被点击/购买上百万次,或者某条爆炸性新闻等被大量浏览,此时会造成一个较大的请求Redis量,这种情况下就会造成热点Key问题。
2、请求分片集中,超过单台Redis服务器的性能极限。
在服务端读数据进行访问时,往往会对数据进行分片切分,例如采用固定Hash分片,hash落入同一台redis服务器,如果瞬间访问量过大,超过机器瓶颈时,就会导致热点 Key 问题的产生。
1.2 热点Key的危害
缓存击穿,压垮redis服务器,导致大量请求直接发往后端服务,并且DB本身性能较弱,很可能进一步导致后端服务雪崩。
1.3 如何解决热key问题
Redis集群扩容:增加分片副本,分摊客户端发过来的读请求
读写分离:主节点处理写请求,从节点处理读请求
使用二级缓存:将热key存放一份到JVM本地内存中,减少Redis的读请求
二、什么是Big key
Redis中的大key问题指的是某个key对应的value值所占的内存空间比较大,这会导致Redis的性能下降、内存不足、数据不均衡以及主从同步延迟等一系列问题。大key的具体定义并不固定,通常认为字符串类型的key对应的value值占用空间大于1MB,或者集合类型的key元素数量超过1万个,就视为大key。但这一标准也会根据Redis的实际运用以及业务需求来综合评估。
本质上是大value问题。key往往是程序可以自行设置的,value往往不受程序控制,因此可能导致value很大。
用几个实际的例子对大Key的特征进行描述:
● 一个String类型的Key,它的值为5MB(数据过大);
● 一个List类型的Key,它的列表数量为20000个(列表数量过多);
● 一个ZSet类型的Key,它的成员数量为10000个(成员数量过多);
● 一个Hash格式的Key,它的成员数量虽然只有1000个但这些成员的value总大小为100MB(成员体积过大);
在实际业务中,大Key的判定仍然需要根据Redis的实际使用场景、业务场景来进行综合判断。通常都会以数据大小与成员数量来判定。
2.1 Big Key产生的场景
1、redis数据结构使用不恰当
将Redis用在并不适合其能力的场景,造成Key的value过大,如使用String类型的Key存放大体积二进制文件型数据。
2、未及时清理垃圾数据
没有对无效数据进行定期清理,造成如HASH类型Key中的成员持续不断的增加。即一直往value塞数据,却没有删除机制,value只会越来越大。
3、对业务预估不准确
业务上线前规划设计考虑不足没有对Key中的成员进行合理的拆分,造成个别Key中的成员数量过多。
4、明星、网红的粉丝列表、某条热点新闻的评论列表
假设我们使用List数据结构保存某个明星/网红的粉丝,或者保存热点新闻的评论列表,因为粉丝数量巨大,热点新闻因为点击率、评论数会很多,这样List集合中存放的元素就会很多,可能导致value过大,进而产生Big Key问题。
2.2 大key问题的影响
- 内存占用过高:大key占用过多的内存空间,可能导致可用内存不足,从而触发内存淘汰策略。
- 性能下降:大key的读写操作会消耗更多的CPU和网络资源,导致Redis整体性能下降。
- 阻塞操作:删除或修改大key时,可能会阻塞Redis实例,影响其他操作。
- 数据不均衡:大key的存在可能导致数据在Redis集群中的分布不均衡。
- 主从同步延迟:在主从复制场景中,大key的同步可能会增加延迟。
2.3 如何识别Big Key?
- 使用
SCAN
命令结合其他命令(如STRLEN
、LLEN
、SCARD
、HLEN
等)逐步遍历数据库中的所有key,识别出大key。 - 使用
redis-cli
命令客户端,连接Redis服务时加上--bigkeys
参数,可以扫描每种数据类型数量最大的key。 - 使用开源工具如Redis RDB Tools分析RDB文件,扫描出Redis中的大key。
2.4 如何解决Big Key问题?
1.分析原因
- 分析为何会产生大key,并根据业务场景考虑是否可以通过更好的设计来避免大key的产生。
2.拆分大key
- 如果大key是不可避免的,尝试将其拆分成更多的小key来分散数据。例如,对于列表、集合和有序集合,可以通过散列(hashing)某个属性,把它们分散到不同的小key中。
- 对于哈希表,可以使用一致性哈希等算法将大哈希表拆分成多个小哈希表。
3.设置合理的过期时间
- 为每个key设置过期时间,并设置合理的过期时间,以便在数据失效后自动清理,避免长时间累积的大key问题。
4.启用内存淘汰策略
- 启用Redis的内存淘汰策略,如LRU(Least Recently Used,最近最少使用),以便在内存不足时自动淘汰最近最少使用的数据,防止大key长时间占用内存。
5.使用数据压缩
- 对于String类型的大key,可以使用压缩算法(如LZF、QUICKLZ、GZIP等)减少value的大小。
6.渐进式删除
- 如果要删除大key,为了避免一次性删除所带来的长时间阻塞,可以使用Redis的
HSCAN
、SSCAN
、ZSCAN
和SCAN
命令,配合DEL
命令对大key进行渐进式删除。
7.数据迁移
- 如果单个Redis实例无法处理大key问题,可以考虑将数据迁移到使用集群,以此来分散负载和存储。
8.优化数据结构
- 优化数据结构可能是处理大key最有效的方法。如果不必使用哈希表、列表、集合或有序集合的全部特性,可以考虑使用更简单的数据结构来替代。
9.监控与预防
- 定期监控Redis实例的内存使用情况和各种key的大小,能够帮助及时发现并处理大key问题。
- 在开发和部署Redis系统时充分考虑大key问题,并采取相应的措施来预防和避免这些问题的出现。