缓存穿透
访问不存在的key,导致每次都去DB查找,从而失去了缓存的意义,也加大了DB的压力。失去了缓存的意义,访问这些key频次高的话,会加大DB压力,甚至导致DB崩溃。
解决方案
- 使用布隆过滤器,将所有存在的key哈希到一个足够大的bitmap中。一个不存在的key一定能被挡住,但如果结果告诉程序某个key存在,并不一定存在(因为存在hash碰撞)。
- 回填空值到缓存,需要注意缓存过期时间
缓存击穿
由于设置了过期时间,如果在同一时间内一个key(热key)失效,如果某些时间内被高频词访问,那么造成缓存击穿。(缓存里没有,DB里有)
解决方案
redis写key的时候,先对key加锁,然后在读mysql,这样可防止同意时刻大量读请求到达mysql。
缓存雪崩
由于设置相同的过期时间,导致同一时间内大量的key失效。DB压力过大,甚至导致DB崩溃。
解决方案
设置过期时间时随机配置过期时间。
大键
数据量大的 key ,由于其数据大小远大于其他key,导致经过分片之后,某个具体存储这个 big key 的实例内存使用量远大于其他实例,造成内存不足,拖累整个集群的使用。
大key相关的删除或者自动过期时,会出现qps突降或者突升的情况,极端情况下,会造成主从复制异常,Redis服务阻塞无法响应请求。
key类型 field数量耗时
Hash~100万~1000ms
List~100万~1000ms
Set~100万~1000ms
Sorted Set~100万~1000ms
如何判断大键
- 字符串类型:一般认为超过 10k 的就是 bigkey,但是这个值和具体的 OPS 相关。
- 非字符串类型:体现在哈希,列表,集合类型元素过多。
Redis 4.0之前的大key的发现方法
- redis-rdb-tools工具。redis实例上执行bgsave,然后对dump出来的rdb文件进行分析,找到其中的大KEY。
- redis-cli --bigkeys命令。可以找到某个实例5种数据类型(String、hash、list、set、zset)的最大key。
- 自定义的扫描脚本,以Python脚本居多,方法与redis-cli --bigkeys类似。
- debug object key命令。可以查看某个key序列化后的长度,每次只能查找单个key的信息。官方不推荐。
Redis 4.0之前的大key的删除方法
通过hscan、sscan、zscan方式渐进删除若干个元素;但面对过期删除键的场景,这种取巧的删除就无能为力。我们只能祈祷自动清理过期key刚好在系统低峰时,降低对业务的影响。
Redis 4.0之后的大key的发现方法
Redis 4.0引入了memory usage命令和lazyfree机制,不管是对大key的发现,还是解决大key删除或者过期造成的阻塞问题都有明显的提升。
memory usage:默认抽样5个field来循环累加计算整个key的内存大小,样本的数量决定了key的内存大小的准确性和计算成本,样本越大,循环次数越多,计算结果更精确,性能消耗也越多。
Redis 4.0之后的大key的删除方法
lazyfree机制:Lazyfree的原理是在删除的时候只进行逻辑删除,把key释放操作放在bio(Background I/O)单独的子线程处理中,减少删除大key对redis主线程的阻塞,有效地避免因删除大key带来的性能问题。在此提一下bio线程,很多人把Redis通常理解为单线程内存数据库, 其实不然。Redis将最主要的网络收发和执行命令等操作都放在了主工作线程,然而除此之外还有几个bio后台线程,从源码中可以看到有处理关闭文件和刷盘的后台线程,以及Redis4.0新增加的lazyfree线程。
解决方案
string类型
string类型的big key,建议不要存入redis,用文档型数据库MongoDB代替或者直接缓存到CDN上等方式优化。有些 key 不只是访问量大,数据量也很大,这个时候就要考虑这个 key 使用的场景,存储在redis集群中是否是合理的,是否使用其他组件来存储更合适;如果坚持要用 redis 来存储,可能考虑迁移出集群,采用一主一备(或1主多备)的架构来存储。
hash, set,zset,list
可以将这些元素分拆。以hash为例,原先的正常存取流程是 hget(hashKey, field) ; hset(hashKey, field, value)
固定一个桶的数量,每次存取的时候,先在本地计算field的hash值,模除 10000,确定了该field落在哪个key上。
bitmap/布隆过滤器过大
过大可能引发内存淘汰机制,导致部分数据被移除。
解决方案
对大的bitmap拆分。利用多个hash函数计算key的哈希值后,最终key都落在一个bitmap上。
要保证多个hash函数计算后路由到同一个节点,那么才能提高查询效率。否则拆分后要查询多个节点才能拿到结果。拆分后bitmap虽然变小,当作为布隆过滤器使用时,其误判概率并不会随之增大。因为误判是概率是与哈希函数个数,集合元素数量及bitmap大小相关。