Redis 的 BigKey、HotKey 又引发了线上事故！ _Redis

当一个较大的key存在时，持续新增，key所占内存会越来越大，严重时会导致内存数据溢出；当key过期需要删除时，由于数据量过大，可能发生主库较响应时间过长，主从数据同步异常（删除掉的数据，从库还在使用）。
问题的严重性首先，要申明一下，问题的严重性。
BigKey（大key）和HotKey（热key）的问题是较常见。
这类问题不止会使服务的性能下降，还会影响用户正常使用功能，
甚至会造成大范围的服务故障，故障有时还会发生连环效应，导致更加严重的后果，发生系统的雪崩，造成巨大的经济损失，巨大的品牌损伤。
所以，在 redis 运维过程中，由于 Bigkey 的存在，DBA 也一直和业务开发方强调 Bigkey 的规避方法以及危害。
在开发的过程中，开发同学，也需要十分重视和预防这个问题。
一、什么是BigKey、HotKey？什么是BigKey俗称“大key”，是指redis在日常生产的过程中，某些key所占内存空间过大。
通俗来说，redis是key-value的存储方式，当一个key所对应的存储数值达到一定程度，就会出现大key的情况。
redis里有多种数据存储结构，如String、List、Hash等，每种存储结构都有能够承载的数据限值。当一个key包含的内容接近限制，或者高于平均值，大key就产生了。关注公众号：码猿技术专栏，回复关键词：1111 获取阿里内部JAVA性能调优手册
在 Redis 中，一个字符串类型最大可以到 512MB，一个二级数据结构（比如 hash、list、set、zset 等）可以存储大约 40 亿个(2^32-1)个元素，
但实际上不会达到这么大的值，一般情况下如果达到下面的情况，就可以认为它是 Bigkey 了。

【字符串类型】：单个 string 类型的 value 值超过 1MB，就可以认为是 Bigkey 。
【非字符串类型】：哈希、列表、集合、有序集合等，它们的元素个数超过 2000 个，就可以认为是 Bigkey 。

什么是HotKey俗称“热key”，一个key对应在一个redis分片上，当短时间内大量的请求打到该分片上，key被频繁访问，该key就是热key 。
当大量的请求，经过分发和计算，最终集中于同一个redis实例下的某个key时，该key由于被请求频率过高，而占用掉了大量资源。
而其他分片，由于key的不合理分配导致请求量较少。
整个redis集群呈现出了资源使用不均衡的现象。
举个例子：一线女明星官宣领证结婚，短时间内该女星微博账号被访问量激增（假设该账号内容被同步在缓存，账号id作为key），微博服务瘫痪（不具备任何实时参考性，仅作为虚拟的例子）。
在该场景下，上述key被大量访问，造成热key 。
总之，在某个Key接收到的访问次数、显著高于其它Key时，我们可以将其称之为HotKey，
从访问量上来说，常见的HotKey如：

某Redis实例的每秒总访问量为10000，而其中一个Key的每秒访问量达到了7000（访问次数显著高于其它Key）
对一个拥有上千个成员且总大小为1MB的HASH Key每秒发送大量的HGETALL（带宽占用显著高于其它Key）
对一个拥有数万个成员的ZSET Key每秒发送大量的ZRANGE（CPU时间占用显著高于其它Key）

二、服务中的bigkey和hotkey会导致什么问题我们可以通过上述两种key的特性，来简单分析可能出现的几种问题。
第1：bigkey的问题主要的问题是一个key所占空间太大，内存空间分配不均衡（小tips：redis是内存型key-value数据库）。那就可能引发以下问题：
1.数据请求大量超时：
redis是单线程的，当一个key数据响应的久一点，就会造成后续请求频繁超时。如果服务容灾措施考虑得不够，会引发更大的问题。
2.侵占带宽网络拥堵：
当一个key所占空间过大，多次请求就会占用较大的带宽，直接影响服务的正常运行。
3.内存溢出或处理阻塞：
当一个较大的key存在时，持续新增，key所占内存会越来越大，严重时会导致内存数据溢出；当key过期需要删除时，由于数据量过大，可能发生主库较响应时间过长，主从数据同步异常（删除掉的数据，从库还在使用）。
第2：hotkey的问题热key，热key的问题是单点访问频率过高。那就可能引发以下问题：
1.分片服务瘫痪：
redis集群会分很多个分片，每个分片有其要处理的数据范围。当某一个分片被频繁请求，该分片服务就可能会瘫痪。