Redis中的Big Key问题是什么？如何解决？#

big key问题指的是Redis中的某个key存储的数据过大（不是指key过大）。 一般情况下认为，String类型大于10kb 以及 集合类型有超过5000个元素 或总大小超过10mb就是big key。

big key会导致几个问题：

1. 阻塞主线程：由于redis是单线程的，若存在一个特别大的key，那每次都得花很长时间去执行命令，这个过程中其他的命令就会被阻塞，导致系统出现大量的慢查询或出现超时错误。
2. 网络拥堵：假设有一个Big key是5MB的字符串，业务接口QPS有1000，那么每秒节点就得向外发送5g的数据，会直接吃满千兆网卡，导致其他服务出问题。
3. 集群倾斜：加入redis集群的某一个槽中有大量的big key，会导致这个节点的内存使用率远超其他节点，会导致资源浪费。
4. 删除卡顿：如果用DEL删除一个集合类型的big key，同样会阻塞主线程很长一段时间。

解决方法：

1. 拆分big key：在业务设计层面把大key拆分，比如Stirng类型存json对象，可以尝试把json对象分为多个，集合类型存100w个内容，可以拆分成100个然后key上加上序号，到时候靠计算取模的方式来获取。
2. 使用压缩算法：可以在存入redis前使用压缩算法压缩内容，比如使用GZip、Snappy等等。存入前压缩，读取时解压。
3. 安全删除：前面说删除big key会出现卡顿，在redis4.0之后，可以使用unlink指令来代替删除，这时被unlink的key会在后台被多线程慢慢释放内存，不阻塞主线程。而4.0以下，则要靠对Hash执行HSCAN指令，每次扫出一定数量的元素，然后再用HDEL删除掉。重复多次这个步骤来删除big key。
4. 引入本地缓存：如果Big key不仅大，读请求还很密集，那就可以考虑再加一层本地缓存，到时候直接走服务器所在的JVM内存，减少对Redis节点的压力。

而最好应对Big Key的方式，就是在代码Review阶段就处理所有可能出现Big key的情况，防患于未然。而遗留的历史问题靠扫描找出，靠拆分、压缩、异步删除的方式来解决。