背景：今天系统多个服务突然告警，限制响应时间超时，原本不到400ms的接口响应时间，好多都变成2s左右，但是过了2分钟就恢复正常

分析：根据查看监控显示，一个使用的第三方的redis超时导致。

结论：删除了一个大key

1.什么是大key?

业务场景中经常会有各种大key的情况， 比如：
(1)单个简单的key存储的value很大
(2)hash、set、zset、list中存储过多的元素（以万为单位）

2.大key的风险?

(1).读写大key会导致超时严重，甚至阻塞服务。

(2).如果删除大key，DEL命令可能阻塞Redis进程数十秒，使得其他请求阻塞，对应用程序和Redis集群可用性造成严重的影响。

(3).建议每个key不要超过M级别。

3.存储优化方案

由于redis是单线程运行的，如果一次操作的value很大会对整个redis的响应时间造成负面影响，应该想办法把这些大key化整为零。
首先是第一种情况
(1)单个简单的key存储的value很大

该对象需要每次都整存整取
可以尝试将对象分拆成几个key-value， 使用multiGet获取值，这样分拆的意义在于分拆单次操作的压力，将操作压力平摊到多个redis实例中，降低对单个redis的IO影响；

该对象每次只需要存取部分数据
可以像第一种做法一样，分拆成几个key-value，也可以将这个存储在一个hash中，每个field代表一个具体的属性，使用hget，hmget来获取部分的value，使用hset，hmset来更新部分属性

(2)hash、set、zset、list 中存储过多的元素
类似于场景一中的第一个做法，可以将这些元素分拆。
以hash为例，原先的正常存取流程是:
hget(hashKey, field);
hset(hashKey, field, value)

现在，固定一个桶的数量，比如10000，每次存取的时候，先在本地计算field的hash值，模除10000，确定该field落在哪个key上。
newHashKey = hashKey + (hash(field) % 10000);
hset(newHashKey, field, value);
hget(newHashKey, field)

set, zset, list 也可以类似上述做法。
但也有些不适合的场景，比如要保证lpop的数据的确是最早push到list中去的，这个就需要一些附加的属性，或者是在key的拼接上做一些工作（比如list按照时间来分拆）。

4.如何优雅地删除各类大Key

从Redis2.8版本开始支持scan命令，通过m次时间复杂度为O(1)的方式，遍历包含n个元素的大key.这样避免单个O(n)的大命令，导致Redis阻塞。

5.Redis Lazy Free

应该从3.4版本开始，Redis会支持lazy delete free的方式，删除大键的过程不会阻塞正常请求。