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问题的影响

1. 内存占用过高：大key占用过多的内存空间，可能导致可用内存不足，从而触发内存淘汰策略。
2. 性能下降：大key的读写操作会消耗更多的CPU和网络资源，导致Redis整体性能下降。
3. 阻塞操作：删除或修改大key时，可能会阻塞Redis实例，影响其他操作。
4. 数据不均衡：大key的存在可能导致数据在Redis集群中的分布不均衡。
5. 主从同步延迟：在主从复制场景中，大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问题，并采取相应的措施来预防和避免这些问题的出现。