Redis 重难点--精准打击（二）Redis缓存和MySQL数据一致性方案详解

目录

前言

什么是数据的一致性

需求起因

缓存和数据库一致性解决方案

1.第一种方案：采用延时双删策略

2、第二种方案：异步更新缓存(基于订阅binlog的同步机制)

其他数据不一致情况及应对策略

针对只读缓存（更新数据库+删除缓存）

针对读写缓存（更新数据库+更新缓存）

数据一致性中需要注意的其他问题有哪些？

k-v大小的合理设置

避免其他问题导致缓存服务器崩溃，进而简直导致数据一致性策略失效

 方案选定的思路

---

前言

对于热点数据（经常被查询，但不经常被修改的数据），我们可以将其放入redis缓存中，以增加查询效率，但需要保证从redis中读取的数据与数据库中存储的数据最终是一致的。

客户端对数据库中的数据主要有两类操作，读(select)与写(DML)。针对放入redis中缓存的热点数据，当客户端想读取的数据在缓存中就直接返回数据，即命中缓存(cache hit)，当读取的数据不在缓存内，就需要从数据库中将数据读入缓存，即未命中缓存(cache miss)。所以读操作并不会导致缓存与数据库中的数据不一致。
  对于写操作(DML)，缓存与数据库中的内容都需要被修改，但两者的执行必定存在一个先后顺序，这可能会导致缓冲与数据库中的数据不再一致，此时主要需要考虑两个问题：
  1、执行顺序的问题：先更新缓存还是先更新数据库？
  2、更新缓存的策略问题：当缓存中的内容变化时，是选择修改缓存(update)，还是直接淘汰缓存(delete)？

针对这两点问题，一共可以分为四种方案：
  1、先更新缓存，再更新数据库；
  2、先更新数据库，再更新缓存；
  3、先淘汰缓存，再更新数据库；
  4、先更新数据库，再淘汰缓存。

什么是数据的一致性

“数据一致” 一般指的是：缓存中有数据，缓存的数据值 = 数据库中的值。

但根据缓存中是有数据为依据，则”一致“可以包含两种情况：

• 缓存中有数据，缓存的数据值 = 数据库中的值（需均为最新值，本文将“旧值的一致”归类为“不一致状态”）
• 缓存中本没有数据，数据库中的值 = 最新值（有请求查询数据库时，会将数据写入缓存，则变为上面的“一致”状态）

”数据不一致“：缓存的数据值 ≠ 数据库中的值；缓存或者数据库中存在旧值，导致其他线程读到旧数据

需求起因

在高并发的业务场景下，数据库大多数情况都是用户并发访问最薄弱的环节。所以，就需要使用redis做一个缓冲操作，让请求先访问到redis，而不是直接访问MySQL等数据库。

这个业务场景，主要是解决读数据从Redis缓存，一般都是按照下图的流程来进行业务操作。

读取缓存步骤一般没有什么问题，但是一旦涉及到数据更新：数据库和缓存更新，就容易出现缓存(Redis)和数据库（MySQL）间的数据一致性问题。

不管是先写MySQL数据库，再删除Redis缓存；还是先删除缓存，再写库，都有可能出现数据不一致的情况。举一个例子：

1.如果删除了缓存Redis，还没有来得及写库MySQL，另一个线程就来读取，发现缓存为空，则去数据库中读取数据写入缓存，此时缓存中为脏数据。

2.如果先写了库，在删除缓存前，写库的线程宕机了，没有删除掉缓存，则也会出现数据不一致情况。

因为写和读是并发的，没法保证顺序,就会出现缓存和数据库的数据不一致的问题。

缓存和数据库一致性解决方案

1.第一种方案：采用延时双删策略

在写库前后都进行redis.del(key)操作，并且设定合理的超时时间。

伪代码如下：

public void write(String key,Object data){
 redis.delKey(key);
 db.updateData(data);
 Thread.sleep(500);
 redis.delKey(key);
 }

具体的步骤就是：

• 先删除缓存；再写数据库；休眠500毫秒；再次删除缓存。

那么，这个500毫秒怎么确定的，具体该休眠多久呢？

需要评估自己的项目的读数据业务逻辑的耗时。这么做的目的，就是确保读请求结束，写请求可以删除读请求造成的缓存脏数据。

当然这种策略还要考虑redis和数据库主从同步的耗时。最后的的写数据的休眠时间：则在读数据业务逻辑的耗时基础上，加几百ms即可。比如：休眠1秒。

设置缓存过期时间

从理论上来说，给缓存设置过期时间，是保证最终一致性的解决方案。所有的写操作以数据库为准，只要到达缓存过期时间，则后面的读请求自然会从数据库中读取新值然后回填缓存。

该方案的弊端

结合双删策略+缓存超时设置，这样最差的情况就是在超时时间内数据存在不一致，而且又增加了写请求的耗时。

2、第二种方案：异步更新缓存(基于订阅binlog的同步机制)

技术整体思路：

MySQL binlog增量订阅消费+消息队列+增量数据更新到redis

• 读Redis：热数据基本都在Redis写MySQL:增删改都是操作MySQL更新Redis数据：MySQ的数据操作binlog，来更新到Redis

Redis更新

1）数据操作主要分为两大块：

• 一个是全量(将全部数据一次写入到redis)一个是增量（实时更新）

这里说的是增量,指的是mysql的update、insert、delate变更数据。

2）读取binlog后分析 ，利用消息队列,推送更新各台的redis缓存数据。

这样一旦MySQL中产生了新的写入、更新、删除等操作，就可以把binlog相关的消息推送至Redis，Redis再根据binlog中的记录，对Redis进行更新。

其实这种机制，很类似MySQL的主从备份机制，因为MySQL的主备也是通过binlog来实现的数据一致性。

这里可以结合使用canal(阿里的一款开源框架)，通过该框架可以对MySQL的binlog进行订阅，而canal正是模仿了mysql的slave数据库的备份请求，使得Redis的数据更新达到了相同的效果。

当然，这里的消息推送工具你也可以采用别的第三方：kafka、rabbitMQ等来实现推送更新Redis。 

其他数据不一致情况及应对策略

根据是否接收写请求，可以把缓存分成读写缓存和只读缓存。

只读缓存：只在缓存进行数据查找，即使用 “更新数据库+删除缓存” 策略；

读写缓存：需要在缓存中对数据进行增删改查，即使用 “更新数据库+更新缓存”策略。

针对只读缓存（更新数据库+删除缓存）

只读缓存：新增数据时，直接写入数据库；更新（修改/删除）数据时，先删除缓存。 后续，访问这些增删改的数据时，会发生缓存缺失，进而查询数据库，更新缓存。

• 新增数据时 ，写入数据库；访问数据时，缓存缺失，查数据库，更新缓存（始终是处于”数据一致“的状态，不会发生数据不一致性问题)

 

• 更新（修改/删除）数据时 ，会有个时序问题：更新数据库与删除缓存的顺序（这个过程会发生数据不一致性问题）

 

在更新数据的过程中，可能会有如下问题：

• 无并发请求下，其中一个操作失败的情况
• 并发请求下，其他线程可能会读到旧值

因此，要想达到数据一致性，需要保证两点：

• 无并发请求下，保证A和B步骤都能成功执行
• 并发请求下，在A和B步骤的间隔中，避免或消除其他线程的影响

接下来，我们针对有/无并发场景，进行分析并使用不同的策略。

A. 无并发情况

无并发请求下，在更新数据库和删除缓存值的过程中，因为操作被拆分成两步，那么就很有可能存在“步骤1成功，步骤2失败” 的情况发生（由于单线程中步骤1和步骤2是串行执行的，不太可能会发生 “步骤2成功，步骤1失败” 的情况）。

(1) 先删除缓存，再更新数据库

 

(2) 先更新数据库，再删除缓存

 

执行时序	潜在问题	结果	是否存在一致性问题
先删除缓存，后更新数据库	删除缓存成功，更新数据库失败	请求无法命中缓存，读取数据库旧值	是
先更新数据库，后删除缓存	更新数据库成功，删除缓存失败	请求命中缓存，读取缓存旧值	是

解决策略：

a.消息队列+异步重试

无论使用哪一种执行时序，可以在执行步骤1时，将步骤2的请求写入消息队列，当步骤2失败时，就可以使用重试策略，对失败操作进行 “补偿”。

 

具体步骤如下：

1. 把要删除缓存值或者是要更新数据库值操作生成消息，暂存到消息队列中（例如使用 Kafka 消息队列）；
2. 当删除缓存值或者是更新数据库值操作成功时，把这些消息从消息队列中去除（丢弃），以免重复操作；
3. 当删除缓存值或者是更新数据库值操作失败时，执行失败策略，重试服务从消息队列中重新读取（消费）这些消息，然后再次进行删除或更新；
4. 删除或者更新失败时，需要再次进行重试，重试超过的一定次数，向业务层发送报错信息。

b.订阅Binlog变更日志

• 创建更新缓存服务，接收数据变更的MQ消息，然后消费消息，更新/删除Redis中的缓存数据；
• 使用 Binlog 实时更新/删除Redis 缓存。利用Canal，即将负责更新缓存的服务伪装成一个 MySQL 的从节点，从 MySQL 接收 Binlog，解析 Binlog 之后，得到实时的数据变更信息，然后根据变更信息去更新/删除 Redis 缓存；
• MQ+Canal策略，将Canal Server接收到的Binlog数据直接投递到MQ进行解耦，使用MQ异步消费Binlog日志，以此进行数据同步；

不管用 MQ/Canal或者MQ+Canal的策略来异步更新缓存，对整个更新服务的数据可靠性和实时性要求都比较高，如果产生数据丢失或者更新延时情况，会造成MySQL和Redis 中的数据不一致。因此，使用这种策略时，需要考虑出现不同步问题时的降级或补偿方案。

B. 高并发情况

使用以上策略后，可以保证在单线程/无并发场景下的数据一致性。但是，在高并发场景下，由于数据库层面的读写并发，会引发的数据库与缓存数据不一致的问题（本质是后发生的读请求先返回了）

(1) 先删除缓存，再更新数据库

假设线程 A 删除缓存值后，由于网络延迟等原因导致未及更新数据库，而此时，线程 B 开始读取数据时会发现缓存缺失，进而去查询数据库。而当线程 B 从数据库读取完数据、更新了缓存后，线程 A 才开始更新数据库，此时，会导致缓存中的数据是旧值，而数据库中的是最新值，产生“数据不一致”。其本质就是，本应后发生的“B线程-读请求” 先于 “A线程-写请求” 执行并返回了。

时间	线程A	线程B	问题
T1	删除数据X的缓存值
T2		1.读取缓存数据X，缓存缺失，从数据库读取数据X	线程B读取到旧值
T3		2.将数据X的值写入缓存	导致其他线程读到旧值
T4	更新数据库中的数据X的值		缓存是旧值，数据库是旧值，导致数据不一致

或者

时间	线程A	线程B	问题
T1	删除数据X的缓存值
T2		1.读取缓存数据X，缓存缺失，从数据库读取数据X	线程B读取到旧值
T3	更新数据库中的数据X的值
T4		2.将数据X的值写入缓存	缓存是旧值，数据库是旧值，导致数据不一致

解决策略：

a.设置缓存过期时间 + 延时双删

通过设置缓存过期时间，若发生上述淘汰缓存失败的情况，则在缓存过期后，读请求仍然可以从DB中读取最新数据并更新缓存，可减小数据不一致的影响范围。虽然在一定时间范围内数据有差异，但可以保证数据的最终一致性。

此外，还可以通过延时双删进行保障：在线程 A 更新完数据库值以后，让它先 sleep 一小段时间，确保线程 B 能够先从数据库读取数据，再把缺失的数据写入缓存，然后，线程 A 再进行删除。后续，其它线程读取数据时，发现缓存缺失，会从数据库中读取最新值。

redis.delKey(X)
db.update(X)
Thread.sleep(N)
redis.delKey(X)

sleep时间：在业务程序运行的时候，统计下线程读数据和写缓存的操作时间，以此为基础来进行估算

时间	线程A	线程C	线程D	问题
T5	sleep(N)	读取到缓存旧值		其他线程可能在此期间读到旧值
T6	删除数据X的缓存值
T7			缓存缺失，从数据库读取数据X的最新值

注意：如果难以接受sleep这种写法，可以使用延时队列进行替代。

先删除缓存值再更新数据库，有可能导致请求因缓存缺失而访问数据库，给数据库带来压力，也就是缓存穿透的问题。针对缓存穿透问题，可以用缓存空结果、布隆过滤器进行解决。

(2) 先更新数据库，再删除缓存

如果线程 A 更新了数据库中的值，但还没来得及删除缓存值，线程 B 就开始读取数据了，那么此时，线程 B 查询缓存时，发现缓存命中，就会直接从缓存中读取旧值。其本质也是，本应后发生的“B线程-读请求” 先于 “A线程-删除缓存” 执行并返回了。

时间	线程A	线程B	潜在问题
T1	更新数据库中的数据X
T2		读取数据X，命中缓存，从缓存中读取X，读取旧值	线程A尚未删除缓存值，导致线程B读到旧值
T3	删除缓存的数据X

或者，在”先更新数据库，再删除缓存”方案下，“读写分离 + 主从库延迟”也会导致不一致：

时间	线程A	线程B	MySQL集群	潜在问题
T1	更新主库 X = 2（原值 X = 1）
T2	删除缓存
T3		查询缓存，没有命中，查询从库，得到旧值（从库 X = 1）
T4		将旧值写入缓存（X = 1）
T5			从库同步完成（主从库 X = 2）	最终 X 的值在缓存中是 1（旧值），在主从库中是 2（新值），也发生不一致

解决方案：

a.延迟消息

凭借经验发送「延迟消息」到队列中，延迟删除缓存，同时也要控制主从库延迟，尽可能降低不一致发生的概率

b.订阅binlog，异步删除

通过数据库的binlog来异步淘汰key，利用工具(canal)将binlog日志采集发送到MQ中，然后通过ACK机制确认处理删除缓存。

c.删除消息写入数据库

通过比对数据库中的数据，进行删除确认 先更新数据库再删除缓存，有可能导致请求因缓存缺失而访问数据库，给数据库带来压力，也就是缓存穿透的问题。针对缓存穿透问题，可以用缓存空结果、布隆过滤器进行解决。

d.加锁

更新数据时，加写锁；查询数据时，加读锁 保证两步操作的“原子性”，使得操作可以串行执行。“原子性”的本质是什么？不可分割只是外在表现，其本质是多个资源间有一致性的要求，操作的中间状态对外不可见。

 

建议：

优先使用“先更新数据库再删除缓存”的执行时序，原因主要有两个：

1. 先删除缓存值再更新数据库，有可能导致请求因缓存缺失而访问数据库，给数据库带来压力；
2. 业务应用中读取数据库和写缓存的时间有时不好估算，进而导致延迟双删中的sleep时间不好设置。

针对读写缓存（更新数据库+更新缓存）

读写缓存：增删改在缓存中进行，并采取相应的回写策略，同步数据到数据库中

• 同步直写：使用事务，保证缓存和数据更新的原子性，并进行失败重试（如果Redis 本身出现故障，会降低服务的性能和可用性）
• 异步回写：写缓存时不同步写数据库，等到数据从缓存中淘汰时，再写回数据库（没写回数据库前，缓存发生故障，会造成数据丢失） 该策略在秒杀场中有见到过，业务层直接对缓存中的秒杀商品库存信息进行操作，一段时间后再回写数据库。

一致性：同步直写 > 异步回写 因此，对于读写缓存，要保持数据强一致性的主要思路是：利用同步直写 同步直写也存在两个操作的时序问题：更新数据库和更新缓存

A. 无并发情况

执行顺序	潜在问题	结果	是否存在一致性问题	解决策略
先更新缓存，后更新数据库	更新缓存成功，更新数据库失败	数据库中为旧值	是	消息队列+重试机制
先更新数据库，后更新缓存	更新数据库成功，更新缓存失败	请求命中缓存，读取缓存旧值	是	消息队列+重试机制；订阅Binlog日志

B. 高并发情况

有四种场景会造成数据不一致：

时序	并发类型	潜在问题	影响程度
先更新数据库，再更新缓存	写+读并发	1.线程A先更新数据库 2.线程B读取数据，命中缓存，读取到旧值 3.线程A更新缓存成功，后续的读请求会命中缓存得到最新值	这种场景下，线程A未更新完缓存之前，在这期间的读请求会短暂读到旧值，对业务短暂影响
先更新缓存，再更新数据库	写+读并发	1.线程A先更新缓存成功 2.线程B读取数据，此时线程B命中缓存，读取到最新值后返回 3.线程A更新数据库成功	这种场景下，虽然线程A还未更新完数据库，数据库会与缓存存在短暂不一致，但在这之前进来的读请求都能直接命中缓存，获取到最新值对业务影响较小
先更新数据库，再更新缓存	写+写并发	1.线程A和线程B同时更新同一条数据 2.更新数据库的顺序是先A后B 3.更新缓存时顺序是先B后A	会导致数据库和缓存的不一致，对业务影响较大
先更新缓存，再更新数据库	写+写并发	1.线程A和线程B同时更新同一条数据 2.更新缓存的顺序是先A后B 3.更新数据库的顺序是先B后A	会导致数据库和缓存的不一致，对业务影响较大

针对场景1和2的解决方案是：保存请求对缓存的读取记录，延时消息比较，发现不一致后，做业务补偿 针对场景3和4的解决方案是：对于写请求，需要配合分布式锁使用。写请求进来时，针对同一个资源的修改操作，先加分布式锁，保证同一时间只有一个线程去更新数据库和缓存；没有拿到锁的线程把操作放入到队列中，延时处理。用这种方式保证多个线程操作同一资源的顺序性，以此保证一致性。

 

其中，分布式锁的实现可以使用以下策略：

分布式锁策略	实现原理
乐观锁	使用版本号、updatetime；缓存中，只允许高版本覆盖低版本
Watch实现Redis乐观锁	watch监控redisKey的状态值，创建redis事务，key+1，执行事务，key被修改过则回滚
setnx	获取锁：set/setnx；释放锁：del命令/lua脚本
Redisson分布式锁	利用Redis的Hash结构作为储存单元，将业务指定的名称作为key，将随机UUID和线程ID作为field，最后将加锁的次数作为value来储存；线程安全

2.3 强一致性策略

上述策略只能保证数据的最终一致性。 要想做到强一致，最常见的方案是 2PC、3PC、Paxos、Raft 这类一致性协议，但它们的性能往往比较差，而且这些方案也比较复杂，还要考虑各种容错问题。 如果业务层要求必须读取数据的强一致性，可以采取以下策略：

（1）暂存并发读请求

在更新数据库时，先在 Redis 缓存客户端暂存并发读请求，等数据库更新完、缓存值删除后，再读取数据，从而保证数据一致性。

（2）串行化

读写请求入队列，工作线程从队列中取任务来依次执行

1. 修改服务Service连接池，id取模选取服务连接，能够保证同一个数据的读写都落在同一个后端服务上
2. 修改数据库DB连接池，id取模选取DB连接，能够保证同一个数据的读写在数据库层面是串行的

（3）使用Redis分布式读写锁

将淘汰缓存与更新库表放入同一把写锁中，与其它读请求互斥，防止其间产生旧数据。读写互斥、写写互斥、读读共享，可满足读多写少的场景数据一致，也保证了并发性。并根据逻辑平均运行时间、响应超时时间来确定过期时间。

public void write() {
    Lock writeLock = redis.getWriteLock(lockKey);
    writeLock.lock();
    try {
        redis.delete(key);
        db.update(record);
    } finally {
        writeLock.unlock();
    }
}
​
public void read() {
    if (caching) {
        return;
    }
    // no cache
    Lock readLock = redis.getReadLock(lockKey);
    readLock.lock();
    try {
        record = db.get();
    } finally {
        readLock.unlock();
    }
    redis.set(key, record);
}

小结

缓存类型	一致性主要策略	优点	缺点	适用场景
读写缓存	更新数据库+更新缓存	缓存中一直会有数据，如果更新操作后会立即再次访问，可以直接命中缓存，能够降低读请求对于数据库的压力	如果更新后的数据，之后很少再被访问到，会导致缓存中保留的不是最热的数据，缓存利用率不高，浪费缓存资源	读写相当
只读缓存	更新数据库+删除缓存	只读缓存中保留的都是热数据，缓存利用率高	删除缓存导致缓存缺失和再加载的过程；缓存缺失时，导致大量请求落到数据库，压垮数据库	读多写少

针对读写缓存时：同步直写，更新数据库+更新缓存

操作顺序	是否有并发请求	潜在问题	结果	应对方案
先更新数据库，再更新缓存	无	数据库更新成功，但更新缓存失败	请求从缓存读到旧数据	重试缓存更新
	写+读	线程A未更新完缓存之前，线程B的读请求会短暂读到旧值	请求从短暂缓存读到旧数据	保存读取记录，做补偿
	写+写	更新数据库的顺序是先A后B，但更新缓存时顺序是先B后A	数据库和缓存数据不一致	分布式锁
先更新缓存，再更新数据库	无	缓存更新成功，但更新数据库失败	数据库存在旧值	重试数据库更新
	写+读	线程A还未更新完数据库，但在这之前进来的读请求都能直接命中缓存，获取到最新值	数据库与缓存存在短暂不一致，但不影响业务	MQ确认数据库更新成功
	写+写	更新缓存的顺序是先A后B，但更新数据库时顺序是先B后A	数据库和缓存数据不一致	分布式锁

针对只读缓存时：更新数据库+删除缓存

操作顺序	是否有并发请求	潜在问题	现象	应对方案
先删除缓存值，再更新数据库	无	缓存删除成功，但数据库更新失败	请求从数据库读到旧数据	重试数据库更新
	有	缓存删除后，尚未更新数据库，有并发读请求	并发请求从数据库读到旧值，并且更新到缓存，导致后续请求都读取旧值	延迟双删；加锁
先更新数据库，再删除缓存	无	数据库更新成功，但缓存删除失败	请求从缓存读到旧数据	重试缓存删除
	有	数据库更新成功后，尚未删除缓存，有并发读请求	并发请求从缓存中读到旧值	延迟消息；订阅变更日志；加锁

较为通用的一致性策略拟定：

在并发场景下，使用 “更新数据库 + 更新缓存” 需要用分布式锁保证缓存和数据一致性，且可能存在”缓存资源浪费“和”机器性能浪费“的情况；一般推荐使用 “更新数据库 + 删除缓存” 的方案。如果根据需要，热点数据较多，可以使用 “更新数据库 + 更新缓存” 策略。

在 “更新数据库 + 删除缓存” 的方案中，推荐使用推荐用 “先更新数据库，再删除缓存” 策略，因为先删除缓存可能会导致大量请求落到数据库，而且延迟双删的时间很难评估。 在 “先更新数据库，再删除缓存” 策略中，可以使用“消息队列+重试机制” 的方案保证缓存的删除。 并通过 “订阅binlog” 进行缓存比对，加上一层保障。

此外，需要通过初始化缓存预热、多数据源触发、延迟消息比对等策略进行辅助和补偿。 【多种数据更新触发源：定时任务扫描，业务系统 MQ、binlog 变更 MQ，相互之间作为互补来保证数据不会漏更新】

数据一致性中需要注意的其他问题有哪些？

 

k-v大小的合理设置

Redis key大小设计： 由于网络的一次传输MTU最大为1500字节，所以为了保证高效的性能，建议单个k-v大小不超过1KB，一次网络传输就能完成，避免多次网络交互；k-v是越小性能越好 Redis 热key：（1） 当业务遇到单个读热key，通过增加副本来提高读能力或是用hashtag把key存多份在多个分片中；（2）当业务遇到单个写热key，需业务拆分这个key的功能，属于设计不合理- 当业务遇到热分片，即多个热key在同一个分片上导致单分片cpu高，可通过hashtag方式打散

避免其他问题导致缓存服务器崩溃，进而简直导致数据一致性策略失效

如缓存穿透、缓存击穿、缓存雪崩、机器故障等问题

问题	描述	解决方案
缓存穿透	查询一个不存在的数据，不能命中缓存，导致每次请求都要到DB去查询，可能导致数据库崩溃	1.查询返回的数据为空，仍把这个空结果进行缓存，但过期时间会比较短； 2.布隆过滤器：将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对DB的查询
缓存击穿	对于设置了过期时间的key，缓存在某个时间点过期的时候，恰好有大量对这个key的并发请求，可能导致大量并发的请求瞬间把数据库压垮	1.使用互斥锁：当缓存失效时，先使用如Redis的setnx去设置一个互斥锁，当操作成功返回时再进行数据库操作并回设缓存，否则重试get缓存的方法； 2.永远不过期：物理不过期，但逻辑过期（后台异步线程去刷新）
缓存雪崩	设置缓存时采用了相同的过期时间，缓存在某一时刻同时失效，导致大量请求访问数据库。 与缓存击穿的区别：雪崩是多key，击穿是单key缓存	1.分散缓存失效时间：在原有的失效时间基础上增加一个随机值； 2. 使用互斥锁，当缓存数据失效时，保证只有一个请求能够访问到数据库，并更新缓存，其他线程等待并重试

 方案选定的思路

1. 确定缓存类型（读写/只读）
2. 确定一致性级别
3. 确定同步/异步方式
4. 选定缓存流程
5. 补充细节

参考：如何保证缓存(redis)与数据库(MySQL)的一致性

认识MySQL和Redis的数据一致性问题

听说Redis都会遇到并发、雪崩等难题？我用10分钟就解决了

最后
文章到这里就先结束了，后面还会持续更新，希望能帮助到各位大佬。如果文章有需要改进的地方还请大佬斧正🎉🎉🎉。
制作不易，希望能得到各位小伙伴儿的支持😘😘😘。
再次感谢大家了🤞🤞🤞。
相信小伙伴们redis数据一致性以及有一定的了解, 更多干货请看这里:更多知识点总结