redis常见问题和解决方案汇总

缓存穿透

访问不存在的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大小相关。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值