前言：
在如今的单体项目中，为了减轻大量相同请求对数据库的压力，我们采取了缓存中间件Redis。核心思想为：把数据写入到redis中，在查询的时候，就可以直接从Redis中拿取数据，这样我们原本对数据库的磁盘操作就变为了对Redis的内存操作，大大减轻了服务器大大压力，但是一个新的问题却应运而生：如何保持缓存与数据库数据的一致性？
目录
前言：
常见的策略：
Cache Aside Pattern：
基于延时双删的对Cache Aside的优化
为什么不使用锁？
总结：
这样的场景其实很常见：
假设线程A对数据库进行了修改，而由于我们的设置，B线程拿取数据是从缓存中拿取的，这就意味着数据库的数据与缓存出现了不一致的情况。
常见的策略：
缓存更新策略常见的有三种：
- 内存淘汰：Redis内存不足的时候，会自动淘汰部分数据，这样就可以在下次查询的时候更新数据，但他对数据的一致性的维护差，但是维护成本低。
- 超时剔除：我们手动为Redis中的数据设置一个有效期，等有效期过了，就需要从数据库中查询，再次写入Redis中，这样就完成了数据的更新，但是这种方式可能会导致Redis的击穿和雪崩问题。
- 主动更新：编写业务逻辑代码，在修改数据库的时候就更新缓存。
今天我们主要讲解一下主动更新策略，而主动更新策略还有三种常见思想：
- Cache Aside Pattern
- 开发人员在更新数据库的时候就直接更新缓存
- Read/Write Through Pattern
- 把缓存和数据库整合成为一个服务，由这个服务来维护一致性
- Write Behind Caching Pattern
- 开发人员只操作缓存，增删改查全部都在缓存中进行，由其他异步线程把缓存数据持久化到数据库，最终保持一致性。
而2和3所展露出来的思想，都有各自的缺点。2是市面上缺乏对应的服务，需要我们自己编写业务代码，提高了我们的业务复杂度；3则是如果我们把对数据的增删改查都放到Redis中，因为Redis是基于内存的，如果服务器宕机或者损坏，就会丢失所有还未写到数据库的数据，这对于一个项目来讲是灾难性的后果。
因此，在今天，我们主要把目光聚集到 Cache Aside Pattern，也就是在更新数据库的时候就更新缓存。
Cache Aside Pattern：
缓存旁路模式的基本流程：
-
读取数据：
- 应用程序从缓存中尝试获取所需数据。
- 如果缓存中存在数据，直接返回给客户端。
- 如果缓存中不存在数据，则进入下一步。
-
获取数据：
- 应用程序从后端存储（如数据库）中读取所需数据。
- 检查后端存储中是否存在数据。
- 如果存在数据，则将数据存储到缓存中，然后返回给客户端。
- 如果不存在数据，则返回空结果给客户端。
-
更新数据：
- 当需要更新数据时，应用程序首先更新后端存储。
- 然后，应用程序手动使缓存失效或删除缓存中对应的数据项，以确保下次读取时可以从后端存储获取最新数据。
因此Cache Aside Pattern是一种先更新数据库，再删除缓存的模式
而在这个操作中，我们需要考虑三个问题：
1.为什么不更新缓存而是选择删除缓存？
我们选择删除缓存，相比较于更新缓存来说，删除缓存的效率更高，如果在更新数据库的时候同步更新缓存，则无用的写操作比较多，不如直接把整个缓存删掉，在查询对应数据的时候重新写入缓存。
2.如何保证缓存与数据库的操作同时成功或失败
在单体项目中，我们使用的是思想是：将缓存与数据库放到一个事务中。
在分布式系统中，我们使用的思想是：利用TCC等分布式事务方案
3.为什么不先删除缓存再更新数据
对于缓存和数据库，一共就两种操作，我们分类讨论：
- 先删除缓存，再操作数据库。
- 先操作数据库，再操作缓存。
这两种操作在多线程的环境下都有自己的弊端，我逐一为大家介绍一下：
在这过程中，我们暂时先不引入锁的概念，在后面我会告诉大家为什么不适用锁来解决这里的数据不一致问题
（1）先删缓存再操作数据库：
在正常情况下：
在这种情况下相安无事，可是我们都知道线程是交替执行的，既然是交替执行的，就极有可能发生以下这种情况：
- 线程1删除缓存后，切换到了线程2
- 线程2查询缓存，未命中，查询数据库，得到旧数据，并写入缓存
- 线程1此时重新拿回执行权，执行更新数据库
也就是说，在这种情况下，发生了缓存中的是旧数据，数据库的是新数据的错误事件。
（2）先操作数据库再删除缓存：
在正常情况下：
在这种情况下相安无事，可是我们都知道线程是交替执行的，既然是交替执行的，就极有可能发生以下这种情况：
- 线程2拿到执行权之后，恰巧缓存数据过期，需要查询数据库，此时查到了旧数据
- 切换到线程1,线程1此时进行更新数据库。更新结束后。
- 切换到线程2，线程2把查询到的旧数据写入缓存
- 此时又到线程1，删除了缓存
也就是说，在这种情况下，也发生了缓存中是旧数据，数据库是新数据的错误数据
由此可以看出，其实两个操作都会有相同的问题，那么我们应该使用哪一种策略呢？
答案是先操作数据库，再删除缓存。这是因为这种操作下的异常情况出现的概率要小很多，首先要恰好缓存数据过期。
而且，写入缓存本就是一个很快的过程，从理论上讲，在一个时间切片内，查询缓存未查中，转向查数据库和写入缓存是可以执行完的，这也就意味着很难出现 查询缓存未查中，查询数据库后，转向线程1，执行更加费时的更新数据库操作。
简单的讲就是说：在先操作数据库，再删除缓存这种操作思想的背景下，出现问题的概率要比先删除缓存，再更新数据库要小。
再者来说，就算是基于两个操作都异常的情况下，但我们先删除缓存再更新数据库的时候，我们的缓存与数据库不一致的时间要长：
在这些步骤完成后，数据库与缓存数据不一致的时期为：
直到缓存失效或者下一次删除缓存
而在先更新数据库再删除缓存的时候，我们的缓存与数据库不一致时间要短
也就是说当先删除缓存，再更新数据库的时候，缓存与数据库数据不一致的时间只有：
从线程2写入缓存到线程1删除缓存
也就是说先更新数据库，再删除缓存这种操作，所带来的缓存与数据库数据不一致的窗口时期，也比先删缓存在更新数据库要短。
而且我们都知道:Redis是基于内存的，也就是说它没有回滚操作。当我们的数据库更新异常时，如果是先更新数据库，再删除缓存的策略，此时我们只需要回滚数据库就可以了。而如果是先删除缓存，再更新数据库这种机制，那就完蛋了，因为Redis没有回滚操作，除非我们自己手动实现，这样又会增加业务的复杂程度。
也就是说，在不引入锁的前提下，先操作数据库再删除缓存 这种操作策略，可以在最大程度上保持缓存与数据库数据的一致性。
而我们的Cache Aside 这种策略模式，不适合于需要高命中率的场景，因为他会对缓存进行频繁的删除。换句话来讲，Cache Aside 更加适合读多写少的场景。
基于延时双删的对Cache Aside的优化
我们可以从上面的图中看出，即使是使用先删数据库，再删缓存的情况下，也仍然有数据不一致的窗口期，而且我们给出的图还是理想的情况下，而在实际生活中，是很有可能出现写入缓存在删除缓存之后的这种极端情况的，用图可以表示为：
一旦出现这种情况，那么数据不一致的窗口期就变为了：直到缓存过期或者下一次删除缓存。
那么为了解决这种问题的出现，一种新的技术就出现了：延时双删
我们用人话来理解一下延时双删的思想：既然删除缓存之后，又把旧的数据写入缓存了，那我们再删一次不就好了！
延时双删 就是当我们第一次删除缓存之后，设置一个定时任务或者MQ延迟消息，设置在几秒之后再次删除缓存，这样就避免了出现这种极端情况导致的数据不一致窗口期大大加长。
如果想要保证缓存与数据库数据强一致，那么就需要使用锁，而基于Cahce Aside + 延时双删这种模式，你再怎么优化，也不可以做到缓存与数据库数据强一致
为什么不使用锁？
如果只是为了解决缓存和数据库数据不一致的情况，那么是可以用分布式锁的。但是分布式锁会导致整个项目的并发性彻底完蛋。因此我们尽量要在无锁的情况下解决这种问题。
总结：
面对数据库与缓存的数据不一致的问题，我们普遍采用Cache Aside + 延时双删的无锁思想来解决这个问题。但是它并不能真正解决，只是在不断的缩短数据不一致的窗口期，如果想要做到数据库与缓存数据的强一致，那么就需要使用分布式锁，来使得单个线程操作数据库和Redis具有原子性，但是大量的分布式锁会导致项目的并发性完蛋。因此解决此类问题，还是要在无锁的思想基调下进行。
如果我的内容对你有帮助，请点赞，评论，收藏。创作不易，大家的支持就是我坚持下去的动力！
