文章目录
- 缓存雪崩、击穿、穿透
- 更新数据时，如何保证数据库和缓存的一致性？
-
- [1. 先更新数据库？先更新缓存？](#1. 先更新数据库？先更新缓存？)
- [2. Cache Aside策略](#2. Cache Aside策略)
-
- [① 先更新数据库，再删除缓存](#① 先更新数据库，再删除缓存)
- [② 先删除缓存，再更新数据库](#② 先删除缓存，再更新数据库)
缓存雪崩、击穿、穿透
一般用户数据存储于磁盘，读写速度慢。
使用redis作为缓存，相当于数据缓存在内存，大大提高系统性能
redis作为缓存，就会有缓存异常的三个问题
1.缓存雪崩
缓存都设置了过期时间
造成缓存雪崩
-
大量缓存数据在同一时间过期
-
redis故障宕机
若此时有大量用户请求，无法在redis处理，都直接访问数据库 => 数据库压力骤增（严重造成数据库宕机） => 形成一系列连锁反应 => 整个系统崩溃
解决缓存雪崩
=> 大量缓存数据在同一时间过期时：
-
均匀设置过期时间（对缓存数据的过期时间加上随机数，保证数据不会在同一时间过期）
-
互斥锁（当业务线程在处理用户请求时，如果发现访问的数据不在redis里，加互斥锁，保证同一时间内只有一个请求来构建缓存（从数据库读取数据，再将数据更新到redis），当缓存构建完成后，再释放锁。）
注：互斥锁设置超时时间，否则若出现请求发生意外阻塞，导致其他请求也一直拿不到锁
-
后台更新缓存（让缓存"永久有效"，将更新缓存的工作交由后台线程定时更新）
当系统内存紧张时，有些缓存数据被"淘汰"，在"淘汰"和下次更新时间内，业务线程读取失败就以为是数据丢失，解决方法：
-
后台线程负责定时更新缓存，同时频繁地检测缓存是否失效，若失效，可进行构建缓存
检测时间间隔不能太长，太长导致用户获取的数据是空值而不是真正的数据，检测时间间隔最好是毫秒级，用户体验一般
-
业务线程发现缓存数据失效后，通过消息队列发送一条消息通知后台线程更新缓存。后台线程收到消息后，更新前判断缓存是否存在，不存在则进行构建缓存。
缓存更新及时，用户体验好
注： 后台更新缓存机制适合进行缓存预热（业务刚上线时，提前缓存数据，不是等待用户访问才来触发缓存构建）
-
=> Redis故障宕机时：
-
服务熔断或请求限流机制
服务熔断：暂停业务应用对缓存服务的访问，直接返回错误，不再继续访问数据库，直到redis恢复正常。
请求限流机制：只将少部分请求发送到数据库进行处理，再多的请求就在入口直接拒绝服务，等到Redis恢复正常 并把缓存预热完后。
-
构建redis缓存高可靠集群
通过主从节点的方式构建，若redis缓存的主节点宕机，从节点可以切换成为主节点，继续提供缓存服务
2. 缓存击穿
造成缓存击穿
被频繁访问的热点数据过期，此时大量的请求访问该热点数据，直接访问数据库，数据库很容易被高并发的请求冲垮
缓存击穿可以认为是缓存雪崩的一个子集（对应于大量缓存数据在同一时间过期）
解决缓存击穿
- 互斥锁
- 不给热点数据设置过期时间，由后台异步更新缓存 / 在热点数据准备过期前，提前通知后台线程更新缓存以及重新设置过期时间
3.缓存穿透
对于缓存雪崩、击穿，数据仍然在数据库，一旦缓存恢复相应的数据，就可以减轻数据库的压力
而对于缓存穿透：
用户访问的数据，既不在缓存中，也不在数据库中，导致请求在访问缓存时，发现缓存缺失，再去访问数据库，发现数据库也没有要访问的数据，没办法构建缓存来服务后续请求。当有大量的这样的请求时，数据库的压力骤增
造成缓存穿透
- 业务误操作，缓存中数据和数据库数据都被误删除
- 黑客恶意攻击，故意大量访问某些读取不存在数据的业务
解决缓存穿透
-
非法请求的限制
判断请求参数是否含有非法值？请求字段是否存在？
-
缓存空值或默认值
当线上业务发现缓存穿透时，针对查询的数据，在缓存中设置一个空值或默认值，后续请求可以从缓存中读取到数据，而不会继续查询数据库
-
使用布隆过滤器快速判断数据是否存在，避免通过查询数据库来判断数据是否存在。
写入数据库数据时，使用布隆过滤器做标记，当业务线程确认缓存失效后，可以通过查询布隆过滤器判断数据是否存在。（大量请求只会查询布隆过滤器和redis，而不会查询数据库）
注：布隆过滤器的实现
设此时有3个哈希函数，位图数组长度为8，数据库写入数据x：
将该数据x得到的三个哈希值 % 位图数据长度得到三个数组下标，填入1。
当业务线程查询数据是否存在于数据库时，查询 1、4、6下标的值是否为1，若有一个为0，则说明不存在
（存在哈希冲突，故若查询布隆过滤器说数据存在于数据库，此时数据不一定在数据库；但是查询到数据不存在时，数据一定不存在）
更新数据时，如何保证数据库和缓存的一致性？
1. 先更新数据库？先更新缓存？
在数据更新时，先更新数据库还是先更新缓存，都会存在并发问题，当两个请求并发更新同一条数据时，可能会出现缓存和数据库中数据不一致的现象。
解决方案
- 更新缓存之前加分布式锁，保证同一时间只运行一个请求更新缓存，但对写入性能造成影响
- 更新完缓存后，给缓存加上较短的过期时间，即使不一致，但也会很快过期
2. Cache Aside策略
旁路缓存策略： 在更新数据时，不更新缓存，更新数据库，删除缓存， 当读取数据发现缓存中无该数据时，再从数据库中读取数据，并且写入缓存。
（删除缓存，不更新缓存是懒加载思想的应用）
分为读策略、写策略
- 写策略
- 更新数据库中的数据
- 删除缓存中的数据
- 读策略
- 若读取的数据命中缓存，则直接返回数据
- 若读取的数据没有命中缓存，则从数据库中读取数据，再将该数据写入缓存，并且返回给用户
例：请求A读取数据，请求B更新数据
此时数据库中为21，缓存中为20
该情况出现概率不高，因为缓存的写入通常远远快于数据库的写入
① 先更新数据库，再删除缓存
故 先更新数据库，再删除缓存 可以保证"数据一致性"，并且对缓存加上过期时间，可以保证最终一致性
问题：
-
先更新数据库，再删除缓存会导致缓存命中率降低。
若对缓存命中率有要求，可以采用更新数据库+更新缓存，解决方案见1.
-
这种方法保证数据一致性的前提是 更新数据库和删除缓存都能正常执行成功。
（删除缓存失败时，可能出现缓存中为旧数据，数据库中为新数据）
保证更新数据库、删除缓存都执行成功
采用异步缓存，保证第二个操作执行成功
- 重试机制 => 引入消息队列，将删除缓存操作的数据加入消息队列，由消费者操作数据
- 如果删除缓存失败，从消息队列重新读取需要删除的数据，再次删除缓存（若多次删除失败，需要向业务层发送报错信息）
- 如果删除缓存成功，把数据从消息队列移除，避免重复操作
- 订阅 MySQL binlog，再操作缓存
- 先更新数据库，再删除缓存，当更新数据库成功，就会产生一条变更日志，记录在binlog里。于是可以订阅binlog日志，拿到具体要操作的数据，再执行缓存删除。
- Canal模拟MySQL的主从复制的交互协议，把自己伪装成从节点，向MySQL主节点发送dump请求，MySQL收到请求后，推送binlog给Canal，Canal解析Binlog字节流后，转换为便于读取的结构化数据，供下游程序订阅使用
- 重试机制 => 引入消息队列，将删除缓存操作的数据加入消息队列，由消费者操作数据
② 先删除缓存，再更新数据库
出现并发问题，造成缓存、数据库数据不一致
解决方案
延迟双删
- 删除缓存
- 更新数据库
- 睡眠
- 再删除缓存
请求A在睡眠时，B能够完成读取数据库数据，并把缺失数据写入缓存，A睡眠完后删除缓存。
请求A的睡眠时间 > 请求B的从数据库读取数据+写入缓存的时间
该方案尽可能保持一致性，建议采用先更新数据库，再删除缓存
互斥锁vs分布式锁
互斥锁：单机情况下，内存中的一个互斥锁就能控制一个程序的线程并发
分布式锁：适用于分布式场景，集群架构，需要"全局锁"实现控制多个程序/多个机器上的线程并发
小林coding图解Redis --- 七