缓存雪崩、击穿、穿透及解决方案_保证缓存和数据库一致性

均匀设置过期时间（对缓存数据的过期时间加上随机数，保证数据不会在同一时间过期）
互斥锁（当业务线程在处理用户请求时，如果发现访问的数据不在redis里，加互斥锁，保证同一时间内只有一个请求来构建缓存（从数据库读取数据，再将数据更新到redis），当缓存构建完成后，再释放锁。）
注：互斥锁设置超时时间，否则若出现请求发生意外阻塞，导致其他请求也一直拿不到锁
后台更新缓存（让缓存“永久有效”，将更新缓存的工作交由后台线程定时更新）
当系统内存紧张时，有些缓存数据被“淘汰”，在“淘汰”和下次更新时间内，业务线程读取失败就以为是数据丢失，解决方法：
1. 后台线程负责定时更新缓存，同时频繁地检测缓存是否失效，若失效，可进行构建缓存
  
  检测时间间隔不能太长，太长导致用户获取的数据是空值而不是真正的数据，检测时间间隔最好是毫秒级，用户体验一般
2. 业务线程发现缓存数据失效后，通过消息队列发送一条消息通知后台线程更新缓存。后台线程收到消息后，更新前判断缓存是否存在，不存在则进行构建缓存。
  
  缓存更新及时，用户体验好
注：后台更新缓存机制适合进行缓存预热（业务刚上线时，提前缓存数据，不是等待用户访问才来触发缓存构建）

=> Redis故障宕机时：

服务熔断或请求限流机制

服务熔断：暂停业务应用对缓存服务的访问，直接返回错误，不再继续访问数据库，直到redis 恢复正常。

请求限流机制：只将少部分请求发送到数据库进行处理，再多的请求就在入口直接拒绝服务，等到Redis恢复正常并把缓存预热完后。
构建redis缓存高可靠集群

通过主从节点的方式构建，若redis缓存的主节点宕机，从节点可以切换成为主节点，继续提供缓存服务

被频繁访问的热点数据过期，此时大量的请求访问该热点数据，直接访问数据库，数据库很容易被高并发的请求冲垮

缓存击穿可以认为是缓存雪崩的一个子集（对应于大量缓存数据在同一时间过期）

对于缓存雪崩、击穿，数据仍然在数据库，一旦缓存恢复相应的数据，就可以减轻数据库的压力

而对于缓存穿透：

用户访问的数据，既不在缓存中，也不在数据库中，导致请求在访问缓存时，发现缓存缺失，再去访问数据库，发现数据库也没有要访问的数据，没办法构建缓存来服务后续请求。当有大量的这样的请求时，数据库的压力骤增

非法请求的限制

判断请求参数是否含有非法值？请求字段是否存在？
缓存空值或默认值

当线上业务发现缓存穿透时，针对查询的数据，在缓存中设置一个空值或默认值，后续请求可以从缓存中读取到数据，而不会继续查询数据库
使用布隆过滤器快速判断数据是否存在，避免通过查询数据库来判断数据是否存在。

写入数据库数据时，使用布隆过滤器做标记，当业务线程确认缓存失效后，可以通过查询布隆过滤器判断数据是否存在。（大量请求只会查询布隆过滤器和redis，而不会查询数据库）

注：布隆过滤器的实现

在这里插入图片描述

设此时有3个哈希函数，位图数组长度为8，数据库写入数据x：

将该数据x得到的三个哈希值 % 位图数据长度得到三个数组下标，填入1。

当业务线程查询数据是否存在于数据库时，查询 1、4、6下标的值是否为1，若有一个为0，则说明不存在

（存在哈希冲突，故若查询布隆过滤器说数据存在于数据库，此时数据不一定在数据库；但是查询到数据不存在时，数据一定不存在）

在这里插入图片描述

更新数据时，如何保证数据库和缓存的一致性？

在数据更新时，先更新数据库还是先更新缓存，都会存在并发问题，当两个请求并发更新同一条数据时，可能会出现缓存和数据库中数据不一致的现象。

旁路缓存策略： 在更新数据时，不更新缓存，更新数据库，删除缓存， 当读取数据发现缓存中无该数据时，再从数据库中读取数据，并且写入缓存。

（删除缓存，不更新缓存是懒加载思想的应用）

分为读策略、写策略

例：请求A读取数据，请求B更新数据

在这里插入图片描述

此时数据库中为21，缓存中为20

该情况出现概率不高，因为缓存的写入通常远远快于数据库的写入

故 先更新数据库，再删除缓存 可以保证“数据一致性”，并且对缓存加上过期时间，可以保证最终一致性

问题：