1.2.2⼤key存在的隐患
⼤key会带来的问题如下：
1、集模式在slot分⽚均匀情况下，会出现数据和查询倾斜情况，部分有⼤key的Redis节点占⽤内存多，QPS⾼。
2、⼤key相关的删除或者⾃动过期时，会出现qps突降或者突升的情况，极端情况下，会造成主从复制异常，Redis服务阻塞⽆法响应请求。基于以上原因，需要对项⽬的缓存进⾏优化。
⼆、优化思路
2.1.2优化⽅案
分析出了⼤key后，就可以按keys的占⽤空间来排序，从前往后按优先级归纳需要优化的keys。项⽬中keys存在的问题在最开始已经总结过。
对于不合理的keys，我们分为两类：
需要优化改进的keys
可以直接删除的keys
⼀、需要优化改进的keys
这就需要针对业务场景做针对性处理了，只能给出⼀些典型例⼦的建议：
选择合理的过期时间，结合业务能短尽量短。
选择合适的数据结构：例如我们现在设计⼀个key⽤于存储⼀些信息。假定key和value的⼤⼩⽤了16个字节，但是由于RedisObject32b(元数据 8b+SDS指针8b+16b key value数据)、dictEntry 32b(三个指针24b，jellmoc分配出32b)。导致⼀个string的key需要存64b，冗余了
优化⽅式：将每个Key取hash code，然后按照业务对指定的业务分成n⽚，⽤hash code对n取模。此时我们使⽤hset info:{hash
Redis具有定时清理过期keys的策略，若有⼤批key在同⼀时间过期，会导致每次采样过期的keys都超过采样数量的25%，循环进⾏删除操作，影响主线程性能。可参考：定期删除策略
重启Redis实例，暴⼒解决，不推荐
使⽤ config set activedefrag yes 命令，调整以下参数进⾏⾃动清理
redis支持的五种数据类型三、优化成果
删除掉⼀批弃⽤的keys后，Redis内存占⽤已经减少了10G。代码上的优化由于业务需求，有些key零散地设置了2-3个⽉的过期时间，两三个⽉过后刚好⼜迎来了淡季，⽆法准确预估优化了多少空间，但是总归还是有⼀定的成果。过程的思路和⽅案仅供参考。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。