1.redis大key
定义
通常以Key的大小和Key中成员的数量来综合判定：
- Key本身的数据量过大
- Key中的成员数过多：
- Key中成员的数据量过大：比如一个hash类型可能key的数量不多，但是数据量太大了
引发的问题
- 客户端执行命令的时长变慢
- Redis内 存满了后就会引发操作阻塞， 甚至引发内存溢出
- 对大Key执行读请求，会使Redis实例的带宽使用率被占满，导致自身服务变慢，同时也容易波及相关的服务。
- 对大Key执行删除操作，容易造成主库较长时间的阻塞，进而可能引发同步中断或主从切换.
产生的原因
- 业务上线前规划设计不足，没有对Key中的成员进行合理的拆分，造成个别Key中的成员数量过多；
- 未定期清理无效数据，造成如HASH类型Key中的成员持续不断地增加；
2.实习中的治理
大key的发现
一般是因为 Redis 网络抖动，或者有部分请求延迟异常等。
但是实习的时候需要被治理的大key，是直接在公司的稳定性治理平台看到的，后来我了解到他们分析的方式也是通过开源工具分析redis 中的RDB快照文件。
然后我治理的大key分两种，
一种是业务功能不用了，代码需要下线。
然后的话就是有一个type是hash的key表示货主和他创建的项目之间的映射，然后把hash拆分成多个string。
其实我当时也讨论过，我们可不可以不拆key去解决问题呢？ 比如可以对这个无效数据进行定期清理，但是说后面业务可能要对货主每个项目做单独处理，所以选择拆分。
拆分之后除了这个性能提升之外，对拆分后的键单独进行操作和管理也比较灵活
改代码的这个过程旧的这个缓存怎么办？
做了一个开关，先走新逻辑，然后如果万一新逻辑有问题就切换到旧逻辑，然后过一段时间观察新逻辑没有问题之后就删除掉旧逻辑的代码和缓存。
引用：这篇文章同时讲了大key和热key问题
