对于冷数据而言，大部分数据可能还没有再次访问到就已经被挤出内存，不仅占用内存，而且价值不大。
 对于热点数据，比如我们的某 IM 产品，生日祝福模块，当天的寿星列表，缓存以后可能读取数十万次，热点数据，缓存才有价值。
 再举个例子，某导航产品，我们将导航信息，缓存以后可能读取数百万次，数据更新前至少读取两次，缓存才有意义。这个是最基本的策略，如果缓存还没有起作用就失效了，那就没有太大价值了。那存不存在，修改频率很高，但是又不得不考虑缓存的场景呢？有！比如，这个读取接口对数据库的压力很大，但是又是热点数据，这个时候就需要考虑通过缓存手段，减少数据库的压力，比如我们的某助手产品的，点赞数，收藏数，分享数等是非常典型的热点数据，但是又不断变化，此时就需要将数据同步保存到 Redis 缓存，减少数据库压力。

 当某一个时刻出现大规模的缓存失效的情况，那么就会导致大量的请求直接打在数据库上面，导致数据库压力巨大，如果在高并发的情况下，可能瞬间就会导致数据库宕机。这时候如果运维马上又重启数据库，马上又会有新的流量把数据库打死。
 解决方案：过期时间加随机数、互斥锁、多级缓存、部署集群。

 缓存击穿是指一个高并发系统中，一个热点的缓存key突然失效（例如，缓存过期），导致这个时刻所有的请求都会落到数据库上，从而引起数据库压力骤增，可能会导致数据库短时间内崩溃。这种情况下，缓存系统没有发挥应有的作用，反而因为缓存key的失效，导致数据库直接面临巨大的访问压力。
 解决方案：互斥锁、逻辑过期、缓存不过期、缓存自动续期。

 指用户查询数据，在数据库没有，自然在缓存中也不会有。这样就导致用户查询的时候，在缓存中找不到，每次都要去数据库再查询一遍，然后返回空（相当于进行了两次无用的查询）。这样请求就绕过缓存直接查数据库，这也是经常提的缓存命中率问题。
 解决方案：布隆过滤器、缓存空值、查询校验。

 系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！
 解决方案如下示例：

• 直接写个缓存刷新页面，上线时手工操作下。
• 数据量不大，可以在项目启动的时候自动进行加载。
• 定时刷新缓存。

 除了缓存服务器自带的缓存失效策略之外（Redis 默认的有 6 种策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有两种：

• 定时去清理过期的缓存；
• 当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。

 两者各有优劣，第一种的缺点是维护大量缓存的 key 是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂！具体用哪种方案，大家可以根据自己的应用场景来权衡。

 当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。
 以参考日志级别设置预案：

• 一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；
• 警告：有些服务在一段时间内成功率有波动（如在 95~100% 之间），可以自动降级或人工降级，并发送告警；
• 错误：比如可用率低于 90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；
• 严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

 服务降级的目的，是为了防止 Redis 服务故障，导致数据库跟着一起发生雪崩问题。因此，对于不重要的缓存数据，可以采取服务降级策略，例如一个比较常见的做法就是，Redis 出现问题，不去数据库查询，而是直接返回默认值给用户。

 参考 Bloom Filteropen in new window。