Redis缓存设计
Posted javathinker
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Redis缓存设计相关的知识,希望对你有一定的参考价值。
缓存更新策略
策略 | 一致性 | 维护成本 |
---|---|---|
LRU、LRF、FIFO | 最差 | 低 |
超时剔除 | 较差 | 较低 |
主动更新 | 强 | 高 |
低一致性业务:最大内存和淘汰策略的方式,maxmemory-policy
高一致性业务:超时剔除和主动更新
缓存穿透
解决缓存穿透 | 适用场景 | 维护成本 |
---|---|---|
缓存空对象 | 数据命中不高,数据频繁变化实时性高 | 代码维护简单,需要过多的缓存空间,数据不一致 |
布隆过滤器 | 数据命中不高、数据相对固定、实时性低 | 代码维护复杂,缓存占用空间小 |
缓存空对象:针对该类对象需设置较短过期时间。
布隆过滤器:将存在的key用布隆过滤器保存起来,如果过滤器认为该信息不存在,那么不会访问存储层。该方法适用于数据命中不高的场景
缓存雪崩
缓存服务器宕机了,或在某一时刻缓存同时到期,导致大量的流量打向后端存储
- 保证缓存层的高可用性
- 依赖隔离组件为后端限流并降级
热点key重建优化
开发人员使用“缓存+过期时间”的策略既可以加速数据读写,又保证数据的定期更新,这种模式基本能够满足绝大
部分需求。但是有两个问题如果同时出现,可能就会对应用造成致命的危害:
当前key是一个热点key(例如一个热门的娱乐新闻),并发量非常大。
重建缓存不能在短时间完成,可能是一个复杂计算,例如复杂的SQL、多次IO、多个依赖等。在缓存失效的瞬
间,有大量线程来重建缓存,造成后端负载加大,甚至可能会让应用崩溃。
要解决这个问题也不是很复杂,但是不能为了解决这个问题给系统带来更多的麻烦,所以需要制定如下目
标:
减少重建缓存的次数
数据尽可能一致
较少的潜在危险
①互斥锁:此方法只允许一个线程重建缓存,其他线程等待重建缓存的线程执行完,重新从缓存获取数据即
可。②永远不过期
永远不过期”包含两层意思: 从缓存层面来看,确实没有设置过期时间,所以不会出现热点key过期后产生的问题,也就是“物理”不过期。 从功能层面来看,为每个value设置一个逻辑过期时间,当发现超过逻辑过期时间后,会使用单独的线程去构建缓存。
从实战看,此方法有效杜绝了热点key产生的问题,但唯一不足的就是重构缓存期间,会出现数据不一致的情况,这取决于应用方是否容忍这种不一致。
以上是关于Redis缓存设计的主要内容,如果未能解决你的问题,请参考以下文章