【redis】 大key解决方案第一步

背景：redis作为缓存，经常困扰的一个问题就是大key，就是key值过大超过1M或者value过多超过1M个或者总的大小超过1MB。

例如：lettuce客户端一直繁忙的处理大key引起的并发症。

 

 比如：系统中用了Set集合，每个item的大小是30个字符，即30字节大小，那么，10W条记录和1W条记录对应的Key大小情况如下：

100000 * 30 字节 = 3，000，000 = 3MByte 3M字节 超级大KEY；！！！

10000 * 30 字节 = 3000，000 = 300KB 超过1W 就是大KEY；！！！！

默认大key的阈值为10240，也就是对于string类型的value大于10240的认为是大key，对于list的话如果list长度大于10240认为是大key，对于hash的话如果field的数目大于10240认为是大key。

【对系统的影响】高并发系统，redis的延迟会是的上层服务堵塞或者延迟，更甚者服务停止（获取不到redis连接或者超时）。

方案：

解决宗旨：redis就是个高速存储服务，必须消灭掉大Key。

解决方案1：按照80 20 原则，只存储有效的数据或者最热的数据。（一般不会影响业务）

解决后效果（ecs机器的cpu负载情况，一天内）左侧是未解决之前，右侧红框是解决之后。

后面文章接着分析，其他解决方案。

参考：

https://redis.io/topics/benchmarks