@[toc] Many small partners should have encountered similar problems during interviews. How to ensure the consistency of cache and database?
If you have researched this question, you should be able to find that this question is actually easy to answer. If you hear or encounter this question for the first time, it is estimated that you will be a little confused. Today we will talk about this topic.
1. Problem Analysis
First let's see why this problem occurs!
In our daily development, in order to improve the data response speed, we may save some hot data in the cache, so that we do not have to query the database every time, which can effectively improve the response speed of the server. Caching is Redis.
Using Redis as a cache does not mean that the cache is Redis, but also needs to be combined with the specific situation of the business. We can divide the data into three levels according to the real-time requirements of different businesses for data. Take e-commerce projects as an example:
- Level 1: Order data and payment flow data: These two pieces of data have high requirements for real-time and accuracy, so generally there is no need to add cache, just operate the database directly.
- Level 2: User-related data: These data are related to users and have the characteristics of reading more and writing less, so we use redis for caching.
- Level 3: Payment configuration information: These data have nothing to do with users, and have the characteristics of small data volume, frequent reading, and almost no modification, so we use local memory for caching.
After selecting the appropriate data to be stored in Redis, next, whenever you want to read data, go to Redis to see if there is any, and return directly if there is; The data read from the database is cached in Redis, which is roughly the process. The process of reading data is actually relatively clear and simple, and there is nothing to say.
However, when the data is stored in the cache, if it needs to be updated, it often brings other problems:
- When there is data that needs to be updated, should the cache or the database be updated first? How to ensure the atomicity of updating the cache and updating the database?
- How do I update the cache when I update it? Modify or delete?
How to do? Normally, we have four options:
- Update the cache first, then update the database.
- Update the database first, then update the cache.
- Retire the cache first, then update the database.
- Update the database first, then retire the cache.
Which one to use?
Before answering this question, let's take a look at three classic caching patterns:
- Cache-Aside
- Read-Through/Write through
- Write Behind
2. Cache-Aside
Cache-Aside，中文也叫旁路缓存模式，如果我们能够在项目中采用 Cache-Aside，那么就能够尽可能的解决缓存与数据库数据不一致的问题，注意是尽可能的解决，并无法做到绝对解决。
Cache-Aside 又分为读缓存和写缓存两种情况，我们分别来看。
2.1 读缓存
先来看一张流程图：
它的流程是这样：
- 读取数据。
- 检查缓存中是否有需要的数据，如果命中缓存（Cache Hit），则直接返回数据。
- 如果没有命中缓存，即 Cache Miss，那么就先去访问数据库。
- 将从数据库中读取到的数据设置到缓存中。
- 返回数据。
这是 Cache-Aside 的读缓存流程。
其实对于读缓存的流程而言，大家一般都没什么异议，有异议的主要是写流程，我们继续来看。
2.2 写缓存
先来看一张流程图：
这个写缓存的流程就比较简单，先更新数据库中的数据，然后删除旧的缓存即可。
流程虽然简单，但是却引伸出来两个问题：
- 为什么是删除旧缓存而不是更新旧缓存？
- 为什么不先删除旧的缓存，然后再更新数据库？
我们来分别回答这两个问题。
为什么是删除旧缓存而不是更新旧缓存？
- 更新缓存，说着容易做起来并不容易。很多时候我们更新缓存并不是简简单单更新一个 Bean。很多时候，我们缓存的都是一些复杂操作或者计算（例如大量联表操作、一些分组计算）的结果，如果不加缓存，不但无法满足高并发量，同时也会给 MySQL 数据库带来巨大的负担。那么对于这样的缓存，更新起来实际上并不容易，此时选择删除缓存效果会更好一些。
- 对于一些写频繁的应用，如果按照
更新缓存->更新数据库的模式来，比较浪费性能，因为首先写缓存很麻烦，其次每次都要写缓存，但是可能写了十次，只读了一次，读的时候读到的缓存数据是第十次的，前面九次写缓存都是无效的，对于这种情况不如采取先写数据库再删除缓存的策略。 - 在多线程环境下，这样的更新策略还有可能会导致数据逻辑错误，来看如下一张流程图：
可以看到，有两个并发的线程 A 和 B：
- 首先 A 线程更新了数据库。
- 接下来 B 线程更新了数据库。
- 由于网络等原因，B 线程先更新了缓存。
- A 线程更新了缓存。
那么此时，缓存中保存的数据就是不正确的，而如果采用了删除缓存的方式，就不会发生这种问题了。
为什么不先删除旧的缓存，然后再更新数据库？
这个也是考虑到并发请求，假设我们先删除旧的缓存，然后再更新数据库，那么就有可能出现如下这种情况：
这个操作是这样的，有两个线程，A 和 B，其中 A 写数据，B 读数据，具体流程如下：
- A 线程首先删除缓存。
- B 线程读取缓存，发现缓存中没有数据。
- B 线程读取数据库。
- B 线程将从数据库中读取到的数据写入缓存。
- A 线程更新数据库。
一套操作下来，我们发现数据库和缓存中的数据不一致了！所以，在 Cache-Aside 中是先更新数据库，再删除缓存。
2.3 延迟双删
其实无论是先更新数据库再删除缓存，还是先删除缓存再更新数据库，在并发环境下都有可能存在问题：
假设有 A、B 两个并发请求：
- 先更新数据库再删除缓存：当请求 A 更新数据库之后，还未来得及进行缓存清除，此时请求 B 查询到并使用了 Cache 中的旧数据。
- 先删除缓存再更新数据库：当请求 A 执行清除缓存后，还未进行数据库更新，此时请求 B 进行查询，查到了旧数据并写入了 Cache。
当然我们前面已经分析过了，尽量先操作数据库再操作缓存，但是即使这样也还是有可能存在问题，解决问题的办法就是延迟双删。
延迟双删是这样：先执行缓存清除操作，再执行数据库更新操作，延迟 N 秒之后再执行一次缓存清除操作，这样就不用担心缓存中的数据和数据库中的数据不一致了。
那么这个延迟 N 秒，N 是多大比较合适呢？一般来说，N 要大于一次写操作的时间，如果延迟时间小于写入缓存的时间，会导致请求 A 已经延迟清除了缓存，但是此时请求 B 缓存还未写入，具体是多少，就要结合自己的业务来统计这个数值了。
2.4 如何确保原子性
但是更新数据库和删除缓存毕竟不是一个原子操作，要是数据库更新完毕后，删除缓存失败了咋办？
对于这种情况，一种常见的解决方案就是使用消息中间件来实现删除的重试。大家知道，MQ 一般都自带消费失败重试的机制，当我们要删除缓存的时候，就往 MQ 中扔一条消息，缓存服务读取该消息并尝试删除缓存，删除失败了就会自动重试。如果小伙伴们还不懂 RabbitMQ 的使用，可以在公众号江南一点雨后台回复 rabbitmq，有免费的视频+文档。
3. Read-Through/Write-Through
这种缓存操作模式，松哥印象最深的是在 Oracle Coherence 中有应用，不知道小伙伴们有没有用过 Oracle Coherence，这是一个内存数据网格，通过这个，应用开发人员和管理人员可快速访问键值数据，Coherence 可提供集群式低延迟数据存储、多语言网格计算和异步事件流处理，从而为客户企业应用赋予超高水平的可扩展性和性能。
Oracle Coherence 我们就不讨论了，我们就来说说 Read-Through。
3.1 Read-Through
这里为了省事，我就不自己画图了，网上找了一张图片，如下：
乍一看，很多人感觉这和 Cache-Aside 一样呀，没啥区别！是的，单看流程是不太容易看到区别。
Read-Through 是一种类似于 Cache-Aside 的缓存方法，区别在于，在 Cache-Aside 中，由应用程序决定去读取缓存还是读取数据库，这样就会导致应用程序中出现了很多业务无关的代码；而在 Read-Through 中，相当于多出来了一个中间层 Cache Middleware，由它去读取缓存或者数据库，应用层的代码得到了简化，松哥之前写过 Spring Cache 的用法，大家回忆下 Spring Cache 中的 @Cacheable 注解，感觉像不像 Read-Through？
我画一个简单的流程图大家来看下：
可以看到，和 Cache-Aside 相比，其实就相当于是多了一个 Cache Middleware，这样我们在应用程序中就只需要正常的读写数据就行了，并不用管底层的具体逻辑，相当于把缓存相关的代码从应用程序中剥离出来了，应用程序只需要专注于业务就行了。
3.2 Write-Through
Write-Through 其实也是差不多，所有的操作都交给 Cache Middleware 来完成，应用程序中就是一句简单的更新就行了，我们来看看流程：
在 Write-Through 策略中，所有的写操作都经过 Cache Middleware，每次写入时，Cache Middleware 会将数据存储在 DB 和 Cache 中，这两个操作发生在一个事务中，因此，只有两个都写入成功，一切才会成功。
这种写数据的优势在于，应用程序只与 Cache Middleware 对话，所以它的代码更加干净和简单。
4. Write Behind
Write-Behind 缓存策略类似于 Write-Through 缓存，应用程序仅与 Cache Middleware 通信，Cache Middleware 会预留一个与应用程序通信的接口。
Write-Behind 与 Write-Through 最大的区别在于，前者是数据首先写入缓存，一段时间后（或通过其他触发器）再将数据写入 Database，并且这里涉及到的写入是一个异步操作。这种方式下，Cache 和 DB 数据的一致性不强，对一致性要求高的系统要谨慎使用，如果有人在数据尚未写入数据源的情况下直接从数据源获取数据，则可能导致获取过期数据，不过对于频繁写入的场景，这个其实非常适用。
将数据写入 DB 可以通过多种方式完成：
- 一种是收集所有写入操作，然后在某个时间点（例如，当 DB 负载较低时）对数据源进行批量写入。
- 另一种方法是将写入合并成更小的批次，例如每次收集五个写入操作，然后对数据源进行批量写入。
这个流程图就不想画了，在网上找了一张，小伙伴们参考下：
好啦，和小伙伴们简单聊了下双写一致性的问题，有问题欢迎留言讨论。
参考资料：