如何保证数据库和缓存双写一致性
前言
数据库和缓存（如redis、memcached等）双写数据一致性问题，是一个跟开发语言无关的公共问题。尤其是在高并发的场景下，这个问题变得更加严重。
今天这篇文章主要讲述数据库和缓存双写数据一致性问题常见的解决方案、这些方案中可能存在的坑，以及最优方案是什么。
常见方案
通常情况下，我们使用缓存的主要目的是为了提升查询的性能。大多数情况下，我们是这样使用缓存的：
如下图所示：
graph TD
A[用户请求] --> B[查询缓存]
B --> C{是否存在}
C --> |是|D[返回]
C --> |否|E[查询数据库]
E --> F{是否存在}
F --> |是|G[放入缓存]
F --> |否|D
G --> D这是缓存非常常见的用法。初看好像没有问题，但是忽略了一个非常重要的细节：如果数据库中的某条数据，放入缓存后，又马上被更新了，那么该如何更新缓存呢？
Q：不更新缓存行不行？A：当然不行，如果不更新缓存，在很长的一段时间内（取决于缓存的过期时间），用户请求从缓存中获取到的都可能是旧值，而非数据库的最新值。这就导致了数据不一致的问题。
那么，具体应该如何更新缓存呢？
目前有以下4种方案：
接下来细说这4种方案
先写缓存，再写数据库
对于更新缓存的方案，很多人第一个想到的可能是在写操作中直接更新缓存（写缓存），更直接明了。
那么问题来了：在写操作中，到底是先写缓存，还是先写数据库呢？
在这里先聊聊先写缓存，再写数据库的情况，因为它的问题最严重。
graph TD
A[用户写操作] --> B[写缓存]
B[写缓存] --> C[写数据库]
某一个用户的每一次写操作，如果刚写完缓存，突然网络出现了异常，导致写数据库失败了。
其结果是缓存更新成了最新数据，但数据库没有，这样缓存中的数据就变成了脏数据。如果此时该用户的查询请求，正好读到该数据，就会出现问题，因为该数据在数据库中根本不存在，这个问题非常严重。
缓存的主要目的是把数据库的数据临时保存在内存，便于后续的查询，提升查询速度。但如果某条数据，在数据库中都不存在，缓存这种“假数据”又有啥意义呢？
因此，先写缓存，再写数据库这种方案是不可取的，在实际工作中用的不多。
先写数据库，再写缓存
既然上面的方案行不通，下面聊聊先写数据库，再写缓存的方案。
graph TD
A[用户写操作] --> B[写数据库]
B --> C[写缓存]
如果是并发量比较小，对接口性能要求不太高的系统，可以这么做。
但如果在高并发的业务场景中，写数据库和写缓存，都属于远程操作。为了防止出现大事务，造成的死锁问题，通常建议写数据库和写缓存不要放在同一个事务中。
也就是说在该方案中，如果写数据库成功了，但是写缓存失败了，数据库中已写入的数据就不会回滚。
这样就造成数据库是新数据，而缓存时旧数据，两边数据不一致的情况。
高并发下的问题
假设在高并发的场景中，针对同一个用户的同一条数据，有两个写数据请求：a和b，它们同时请求业务系统。
其中请求a获取的是旧数据，而请求b获取的是新数据，如下图所示：
graph TD
A[用户写操作 请求a] --> |1|B[写数据库]
B --> |2 网络卡顿|C[写缓存]
C --> |6 写入旧值|D[缓存]
E[用户写操作 请求b] --> |3|F[写数据库]
F --> |4|G[写缓存]
G --> |5 写入新值|D
很显然，在这个过程当中，请求b在缓存中的新数据，被请求a的旧数据覆盖了。
也就是说：在高并发场景中，如果多个线程同时执行先写数据库，再写缓存的操作，可能会出现数据库是新值，而缓存中是旧值，两边数据不一致的情况。
浪费系统资源
该方案还有一个比较大的问题就是：每个写操作，写完数据库，会马上写缓存，比较浪费系统资源。
如果写的缓存，并不是简单的数据内容，而是要经过非常复杂的计算得出的最终结果。这样每写一次缓存，都需要经过一次非常复杂的计算，这样就会造成系统资源的浪费，尤其是cpu和内存资源。
还有些比较特殊的业务场景，如写多读少，在这类业务场景中，每个用户的写操作，都要写一次缓存，有点得不偿失。
由此可见，在高并发的业务场景中，先写数据库，再写缓存，这套方案问题挺多的，也不太建议使用。
先删缓存，再写数据库
通过上面的内容可知，如果直接更新缓存的问题很多。
那么，我们换一种思路：不直接更新缓存，改为删除缓存。
删除缓存方案有以下两种：
首先看先删缓存，再写数据库的情况：
graph TD
A[用户写操作] --> B[删除缓存]
B --> C[写数据库]
说白了，在用户的写操作中，先执行删除操作，再去写数据库。这套方案，可以是可以，但是也存在问题。
高并发下的问题
假设在高并发的场景中，同一个用户的同一条数据，有一个读数据请求a，还有另一个写数据请求b（一个更新操作），同时请求到业务系。如下图所示：
graph TD
A[用户写操作 请求a] --> |1|B[删除缓存]
B --> |2 清空|D[缓存]
B --> |8 网络卡顿|C[写数据库]
E[用户查询操作 请求b] --> |3|F[查询缓存]
F --> |4 缓存没数据|D
F --> |5|G[查询数据库]
G --> |6|H[更新缓存 ]
H --> |7 写入旧值|D
在这个过程中，请求a的新值并没有被请求b写入缓存，同样会导致缓存和数据库的数据不一致的情况。
那么，这种场景的数据不一致问题，能否解决呢？
缓存双删
在上面的业务场景中，一个读数据请求，一个写数据请求。当写数据请求把缓存删除之后，读数据请求，可能把当时从数据库查询出来的旧值，写入缓存当中。
有人说，那还不好办，请求d在写完数据库之后，把缓存重新删一次不就行了？
graph TD
A[用户写操作] --> B[删除缓存]
B --> C[写数据库]
C --> |间隔一段时间|D[删除缓存]
我们再重新回顾一下，高并发下一个读数据请求，一个写数据请求导致数据不一致的产生过程：
这样来看确实可以解决缓存不一致的问题。
那么，为什么一定要间隔一段时间之后，才能删除缓存呢？
请求a卡顿结束后，把新值写入数据库后，请求b将数据库中的旧值，更新到缓存中。
接下来，还有一个问题，如果第二次删除缓存时，删除失败了怎么办？
这里先留点悬念，下文会详细说。
先写数据库，再删缓存
从前面得知，先删缓存，再写数据库，在并发的情况下，也可能会出现缓存和数据库的数据不一致的情况。
那么，我们只能寄希望于最后的方案了。
接下来，我们重点看看先写数据库，再删缓存的方案。
graph TD
A[用户写操作] --> B[写数据库]
B --> C[删除缓存]
在这个过程中，只有请求b读了一次旧数据，后来旧数据被请求a及时删除了，看起来问题不大。
但如果是读数据请求先过来呢？
这种情况看起来也没问题呀？
答：对的。
但就怕出现下面这种情况，即缓存自己失效了：
这时，缓存和数据库的数据同样出现不一致的情况了。
但是这种靠还是比较少的，需要同时满足以下条件才可以：
我们都知道查数据库的速度，一般比写数据库要快，更何况写完数据库，还要删除缓存。所以绝大多数情况下，写数据请求比读数据情况耗时更长。
由此可见，系统同时满足上述两个条件的概率非常小。
推荐大家使用先写数据库，再删除缓存的方案，虽说不能100%避免数据不一致问题，但出现该问题的概率，相对于其他方案来说是最小的。
但在该方案中，如果删除缓存失败了怎么办？
删缓存失败怎么办
通过前面我们可以了解到，不管是先写数据库，再删缓存的方案，还是缓存双删的方案，都有一个共同的风险点，即：如果缓存删除失败了，也会导致缓存和数据库的数据不一致。
那么，删除缓存失败怎么办呢？
答：需要加重试机制。
在接口中如果更新数据库成功了，但更新缓存失败了，可以立刻重试3此。如果其中有任何一次成功，则直接返回成功。如果3次都失败了，则写入数据库，准备后续再处理。
当然，如果你在接口中直接同步重试，该接口并发量比较高的时候，可能有点影响接口性能。
这时，就需要改成异步重试了。
异步重试的方案有很多种，比如：
定时任务重试
使用定时任务重试的具体方案如下：
使用定时任务重试的话优缺点：
mq
在高并发的业务场景中，mq（消息队列）是必不可少的技术之一。它不仅可以异步解耦，还能削峰填谷。对保证系统的稳定性是非常有意义的。
使用mq的具体方案如下：
在该方案中，删除缓存可以完全走异步。即用户的写操作，在写完数据库之后，不用立刻删除缓存。而直接发送mq消息，到mq服务器，然后由mq消费者全权负责删除缓存的任务。
因为mq的实时性比较高，因此改良后的方案也是一种不错的选择。
binlog
前面我们聊过，无论是定时任务、还是mq消息队列，做重试机制，对业务都有一定的侵入性。
在使用定时任务的方案中，需要在业务代码中增加额外的逻辑，如果删除缓存失败，需要将数据写入重试表。
而使用mq的方案中，如果删除缓存失败了，需要在业务代码中发送mq消息到mq服务器。
其实，还有一种更优雅的实现，即监听binlog，比如使用：canal等中间件。
具体方案如下：
graph TD
A[用户写操作] --> B[写数据库]
B --> C[返回]
D[binlog]
E[binlog订阅者读取变更数据] --> F[删除缓存]
F --> G[结束]
B --> D
D --> E
这套方案中业务接口确实简化了一些流程，只用关心数据库操作即可，而在binlog订阅者中做缓存删除工作。
但如果只是按照上述方案进行删除缓存，只删除了一次，也可能会失败。这时就需要加上上面聊到的重试机制了。如果删除缓存失败，写入重试表，使用定时任务或重试或写入mq，让mq自动重试。
在binlog订阅这种如果删除缓存失败，则发送一条mq消息到mq服务器，在mq消费者中自动重试5次。如果有任意一次成功，则返回成功。如果重试5次后还是失败，则该消息被自动放入死信队列，后续可能需要人工介入。
