Redis缓存设计

缓存更新策略

策略	一致性	维护成本
LRU、LRF、FIFO	最差	低
超时剔除	较差	较低
主动更新	强	高

低一致性业务：最大内存和淘汰策略的方式，maxmemory-policy

高一致性业务：超时剔除和主动更新

缓存穿透

解决缓存穿透	适用场景	维护成本
缓存空对象	数据命中不高，数据频繁变化实时性高	代码维护简单，需要过多的缓存空间，数据不一致
布隆过滤器	数据命中不高、数据相对固定、实时性低	代码维护复杂，缓存占用空间小

缓存空对象：针对该类对象需设置较短过期时间。

布隆过滤器：将存在的key用布隆过滤器保存起来，如果过滤器认为该信息不存在，那么不会访问存储层。该方法适用于数据命中不高的场景

缓存雪崩

缓存服务器宕机了，或在某一时刻缓存同时到期，导致大量的流量打向后端存储

1. 保证缓存层的高可用性
2. 依赖隔离组件为后端限流并降级

热点key重建优化

开发人员使用“缓存+过期时间”的策略既可以加速数据读写，又保证数据的定期更新，这种模式基本能够满足绝大
部分需求。但是有两个问题如果同时出现，可能就会对应用造成致命的危害：
当前key是一个热点key（例如一个热门的娱乐新闻），并发量非常大。
重建缓存不能在短时间完成，可能是一个复杂计算，例如复杂的SQL、多次IO、多个依赖等。在缓存失效的瞬
间，有大量线程来重建缓存，造成后端负载加大，甚至可能会让应用崩溃。
要解决这个问题也不是很复杂，但是不能为了解决这个问题给系统带来更多的麻烦，所以需要制定如下目
标：
减少重建缓存的次数
数据尽可能一致
较少的潜在危险
①互斥锁：此方法只允许一个线程重建缓存，其他线程等待重建缓存的线程执行完，重新从缓存获取数据即
可。

②永远不过期

永远不过期”包含两层意思： 从缓存层面来看，确实没有设置过期时间，所以不会出现热点key过期后产生的问题，也就是“物理”不过期。 从功能层面来看，为每个value设置一个逻辑过期时间，当发现超过逻辑过期时间后，会使用单独的线程去构建缓存。
从实战看，此方法有效杜绝了热点key产生的问题，但唯一不足的就是重构缓存期间，会出现数据不一致的情况，这取决于应用方是否容忍这种不一致。