Redis 缓存穿透 缓存雪崩 缓存击穿 数据不一致 数据并发竞争 HOT KEY BIG KEY 分布式锁

缓存穿透
缓存雪崩
缓存击穿
数据不一致
数据并发竞争
HOT KEY
BIG KEY
分布式锁

缓存穿透

• 当客户端访问一个key时,在redis中不存在,直接访问到了DB,称为缓存穿透.
  • 解决:
    1.当客户端请求的key在redis中没有时,查询完DB后缓存到redis中
    2.恶意访问,封ip
    3.使用布隆过滤器(Bloom) -> 使用多个hash算法和增长数组长度,可以有限的降低hash碰撞
    
    回顶部

缓存雪崩

• 当redis中的key在同一时间段内全部过期 、 redis重启 或 redis宕机 , 大量的访问直接访问到了DB,称为缓存雪崩
  • 解决:
    1.设置key的过期时间不要太集中
    2.定时刷新,自动访问数据库
    3.设置主从架构
    回顶部

缓存击穿

• 热点key在高并发的时候突然失效,导致直接访问到了DB,称为缓存击穿
  • 解决:
    1.用分布式锁控制访问的线程
    2.热点key不设置超时时间
    3.提前缓存到redis中
    4.配置主从
    回顶部

数据不一致

• 当高并发时,DB进行了数据更新,需要删除redis中的缓存,但是DB还没有进行commit,此时客户端请求了redis,redis中没有,直接访问到了DB,redis又将commit前的数据缓存到了redis中,造成了缓存不一致–>脏读,称为缓存不一致
  • 解决:
    1.定时更新,采用异步操作
    2.采用延时双删,当更新数据时,同时将redis中的缓存(key)删除,过两秒后再删一次,等待下次请求,访问到DB,再缓存到redis
    为避免延时双删失败,可以给key设置过期时间(10s,20s,30s…)
    再或者利用工具(canal)将binlog日志采集发送给mq,通过ACK机制确认,异步删除
    3.使用redis的RedisCache作为二级缓存
    回顶部

数据并发竞争

• 多个客户端同时设置一个key的值,称为数据并发竞争
  • 解决:
    1.采用分布式锁+时间戳
    当客户端1拿到了锁并将时间戳设置了10000.释放后,客户端2拿到了锁,并将时间戳设置了12000,此时当客户端1提交发现10000<12000,就不在进行set操作了
    2.采用mq,将并行的数据进行串行化
    回顶部

HOT KEY

• 热点key,如:秒杀,火爆新闻等,造成了redis的宕机
  • 解决:
    1.预热key,提前将热点key缓存到redis中,并将时间设置足够长或者永久
    2.redis缓存转换为本地缓存.发现热key后,直接加载到tomcat本地缓存中.(前提是数据不轻易变的)
    3.采用主从,将热点数据均存储在主从服务器上,缓解压力
    4.进行熔断限流,限制访问上限5000,超过的直接跳转"服务器忙"等页面
    回顶部

BIG KEY

• 指的是key的value值很大,如:热门话题的讨论,大V的粉丝列表
  • 影响:
    1.主动删除或过期删除时执行时间会很长,造成服务阻塞
    2.redis性能下降,影响主从复制
    3.大key大量占用内存,在集群中无法均衡,如图,大key全部在redis3中,redis3响应很慢,导致整个集群响应很慢
    
  • 解决:
    1.存储了过多的元素,可以进行拆分,一拆二,一拆三,一拆四…
    2.删除时不要用del,用lazy delete -> lazy delete会对要删除的key进行标识,会在另一个线程中进行回收内存
    回顶部

分布式锁

• 单机单线程中使用synchronized;多线程使用分布式锁,利用了redis的单线程,对请求进行了串行化处理.
  • 加锁:使用 NX、EX
  • 删锁:使用 redis+lua脚本 ->

    if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end
    

    回顶部

---

其他章节 -> 跳转

持续更新ing...