缓存预热

• 直接写个缓存刷新页面，上线前手工操作一下

• 数据量不大的时候，可以在项目启动的时候自动加载

• 定时刷新缓存

缓存雪崩

缓存雪崩

当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力

解决方案

• 在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程 查询数据和写缓存，其他线程等待

• 不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀

• 做二级缓存，A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期

缓存击穿

缓存击穿

对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题，这个和缓存雪崩的区别在于这里针对某一key缓存，前者则是很多key

缓存在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮

解决方案

• 使用redis的setnx互斥锁先进行判断，这样其他线程就处于等待状态，保证不会有大并发操作去操作数据库

  if(redis.sexnx()==1){ 
  //先查询缓存 
  //查询数据库 
  //加入缓存 
  }

缓存穿透

缓存穿透

一般的缓存系统，都是按照key去缓存查询，如果不存在对应的value，就应该去后端系统查找（比如DB）。如果key对应的value是一定不存在的，并且对该key并发请求量很大，就会对后端系统造成很大的压力

也就是说，对不存在的key进行高并发访问，导致数据库压力瞬间增大，这就叫做【缓存穿透】

解决方案

• 在服务器端，接收参数时业务接口中过滤不合法的值，null，负值，和空值进行检测和空值

• bloom filter：类似于哈希表的一种算法，用所有可能的查询条件生成一个bitmap，在进行数据库查询之前会使用这个bitmap进行过滤，如果不在其中则直接过滤，从而减轻数据库层面的压力。 采用的是一票否决 只要有一个认为你不存在 就认为你是不存在的

• 空值缓存：一种比较简单的解决办法，在第一次查询完不存在的数据后，将该key与对应的空值也放入 缓存中，只不过设定为较短的失效时间，例如几分钟，这样则可以应对短时间的大量的该key攻击，设置 为较短的失效时间是因为该值可能业务无关，存在意义不大，且该次的查询也未必是攻击者发起，无过久 存储的必要，故可以早点失效

缓存降级

当访问量出现剧增、服务出现问题（相应时间慢或者不响应） 或非核心业务影响到核心流程的性能，还需要保证服务的可用性，即便有损服务

解决方案

• 系统根据一些关键数据进行降级

  配置开关实现人工降级

  参考日志级别

  • 一般：ex有些服务偶尔网络抖动或者服务正在上线超时，可以自定降级

  • 警告：有些服务在一端时间内有波动（95%-100%），可以自定降级或人工降级，还有发送告警

  • 错误：可利用率低于90%，redis连接池被打爆了，数据库连接池被打爆，或者访问量突然猛增到系统能承受的最大阈值，这时候根据情况自动降级或人工降级

  • 严重错误：比如因为特殊原因数据错误了，需要紧急人工降级

• redis服务出问题了， 不去查数据库，而是直接返回一个默认值（自定义一些随机值）

缓存更新

自定义的缓存淘汰策略

• 定期去清理过期的缓存

• 当有用户请求过来时，先判断这个请求用到的缓存是否过期，过期的话就去底层系统得到新数据进行缓存更新

缓存数据库双写一致性

双写 就一定会出现数据一致性问题

解决方案

• 按照先修改数据库再修改缓存来实现

多个系统同时操作（并发）Redis带来的数据问题

系统A、B、C三个系统，分别去操作Redis的同一个Key，本来顺序是1，2，3是正常的，但是因为系统 A网络突然抖动了一下，B，C在他前面操作了Redis，这样数据不就错了么

某个时刻，多个系统实例都去更新某个 key。可以基于 Zookeeper 实现分布式锁。每个系统通过 Zookeeper 获取分布式锁，确保同一时间，只能有一个系统实例在操作某个 Key，别人都不允许读和 写

要写入缓存的数据，都是从 MySQL 里查出来的，都得写入 MySQL 中，写入 MySQL 中的时候必须保存一个时间戳，从 MySQL 查出来的时候，时间戳也查出来

每次要写之前，先判断一下当前这个 Value 的时间戳是否比缓存里的 Value 的时间戳要新。如果是的话，那么可以写，否则，就不能用旧的数据覆盖新的数据