我们在日常开发中，为了提高数据响应速度，可能会将一些热点数据保存在缓存中，这样就不用每次都去数据库中查询了，可以有效提高服务端的响应速度，那么目前我们最常使用的缓存就是 Redis 了。

用 Redis 做缓存，并不是一说缓存就是 Redis，还是要结合业务的具体情况，我们可以根据不同业务对数据要求的实时性不同，将数据分为三级，以电商项目为例：

选中合适的数据存入 Redis 之后，接下来，每当要读取数据的时候，就先去 Redis 中看看有没有，如果有就直接返回；如果没有，则去数据库中读取，并且将从数据库中读取到的数据缓存到 Redis 中，大致上就是这样一个流程，读取数据的这个流程实际上是比较清晰也比较简单的，没啥好说的。

然而，当数据存入缓存之后，如果需要更新的话，往往会来带另外的问题：

怎么办？正常来说，我们有四种方案：

到底使用哪种？

在回答这个问题之前，我们不妨先来看看三个经典的缓存模式：

Cache-Aside 又分为读缓存和写缓存两种情况，我们分别来看。

它的流程是这样：

这是 Cache-Aside 的读缓存流程。

其实对于读缓存的流程而言，大家一般都没什么异议，有异议的主要是写流程，我们继续来看。

这个写缓存的流程就比较简单，先更新数据库中的数据，然后删除旧的缓存即可。

流程虽然简单，但是却引伸出来两个问题：

我们来分别回答这两个问题。

为什么是删除旧缓存而不是更新旧缓存？

可以看到，有两个并发的线程 A 和 B：

那么此时，缓存中保存的数据就是不正确的，而如果采用了删除缓存的方式，就不会发生这种问题了。

为什么不先删除旧的缓存，然后再更新数据库？

这个也是考虑到并发请求，假设我们先删除旧的缓存，然后再更新数据库，那么就有可能出现如下这种情况：

这个操作是这样的，有两个线程，A 和 B，其中 A 写数据，B 读数据，具体流程如下：

一套操作下来，我们发现数据库和缓存中的数据不一致了！所以，在 Cache-Aside 中是先更新数据库，再删除缓存。

假设有 A、B 两个并发请求：

当然我们前面已经分析过了，尽量先操作数据库再操作缓存，但是即使这样也还是有可能存在问题，解决问题的办法就是延迟双删。

延迟双删是这样：先执行缓存清除操作，再执行数据库更新操作，延迟 N 秒之后再执行一次缓存清除操作，这样就不用担心缓存中的数据和数据库中的数据不一致了。

那么这个延迟 N 秒，N 是多大比较合适呢？一般来说，N 要大于一次写操作的时间，如果延迟时间小于写入缓存的时间，会导致请求 A 已经延迟清除了缓存，但是此时请求 B 缓存还未写入，具体是多少，就要结合自己的业务来统计这个数值了。

对于这种情况，一种常见的解决方案就是使用消息中间件来实现删除的重试。大家知道，MQ 一般都自带消费失败重试的机制，当我们要删除缓存的时候，就往 MQ 中扔一条消息，缓存服务读取该消息并尝试删除缓存，删除失败了就会自动重试。如果小伙伴们还不懂 RabbitMQ 的使用，可以在公众号江南一点雨后台回复 rabbitmq，有免费的视频+文档。

Oracle Coherence 我们就不讨论了，我们就来说说 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，这样我们在应用程序中就只需要正常的读写数据就行了，并不用管底层的具体逻辑，相当于把缓存相关的代码从应用程序中剥离出来了，应用程序只需要专注于业务就行了。

在 Write-Through 策略中，所有的写操作都经过 Cache Middleware，每次写入时，Cache Middleware 会将数据存储在 DB 和 Cache 中，这两个操作发生在一个事务中，因此，只有两个都写入成功，一切才会成功。

这种写数据的优势在于，应用程序只与 Cache Middleware 对话，所以它的代码更加干净和简单。

Write-Behind 与 Write-Through 最大的区别在于，前者是数据首先写入缓存，一段时间后（或通过其他触发器）再将数据写入 Database，并且这里涉及到的写入是一个异步操作。 这种方式下，Cache 和 DB 数据的一致性不强，对一致性要求高的系统要谨慎使用，如果有人在数据尚未写入数据源的情况下直接从数据源获取数据，则可能导致获取过期数据，不过对于频繁写入的场景，这个其实非常适用。

将数据写入 DB 可以通过多种方式完成：

这个流程图就不想画了，在网上找了一张，小伙伴们参考下：

好啦，和小伙伴们简单聊了下双写一致性的问题，有问题欢迎留言讨论。

参考资料：