Redis大Key带来的影响以及优化

什么是大Key；

就是单个key数据的数据量过大；

redis6后虽然提供了多线程，但是只是针对io进行了多线程，执行客户端指令的时候依然是单线程的，
比如一条get。set；

场景：

一个视频。将当前视频正在看的人的id全部加载进redis，，，然而最初没想到一个视频会有1w的用户同时观看。。。关键是。前一个员工为了省事。这个数据里还包含了这个用户看过的视频。一次性全部刷进了这个key里面。。造成了这个key特别大；

影响

1.服务器的内存资源十分珍贵，key过大会导致redis频繁的触发lru清理命中率低的key，造成频繁IO影响效率;
2.同时频繁的清理key容器造成缓存穿透
3.集群倾斜：redis集群中是以一个一个的槽进行分片储存的，通过key进行hash运算，来决定存储于哪个槽内，当出现大key的时候，可能第一个分片只能存储100k个数据，二第二个却能储存500k，造成了集群倾斜，负载不均衡。一旦遇到高压场景，很容易造成集群节点处理速度慢
4.单个数据过大，造成单个数据提取速度慢造成线程积压，，redis6 之前执行命令是单线程，读写io也是单线程，但是底层的其他操作是多线程的，比如持久化啊，unlink删除大key之类的；redis6之后虽然支持多线程了，但是它只是针对多线程io提供了支持，，执行用户命令依然是单线程。所以还是会造成线程的积压

优化：

1.首先针对业务调优，
没有人会向下一直翻看，看看究竟是谁看过这个视频，所以优化为只显示最新的100个人。。而且再进行折叠。。。访问量最高的主页面只加载5-10个。。如果真的要看所有人。可以提供另一个接口进行查询，，不要在页面渲染中一次加载全部

2.对大key进行剪裁，减少不必要的数据
这里本来的业务只是显示看这个用户的基本信息。所以只需要加载基本信息就好了，并不需要加载这个用户看过的视频信息，等点开用户头像的时候再另行加载就好了。

3.redis6支持了客户端缓存，我们把他启动

4.定期清理大key，将过大的key进行清除或者优化
这里有一个工具可以使用rdb_bigkeys