聊聊数据库和缓存一致性的几种实现方式
聊聊数据库和缓存一致性的几种实现方式
在分布式环境下，当我们考虑使用AP模型，那么最终一致性的问题就是需要权衡考虑的了
缓存是互联网高并发系统里常用的组件，由于多增加了一层，如果没有正确的使用效果可能适得其反，诸如“缓存是删除还是更新？”，“先操作数据库还是先操作缓存？”都是些老生常谈的话题，今天我们就来聊一聊缓存与数据库的双写一致性的解决方案。
# Cache Aside Pattern
在一开始先科普下最经典的缓存+数据库读写的模式，就是 Cache Aside Pattern。
- 读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。
- 更新的时候，先更新数据库，然后再删除缓存。
为什么是删除缓存，而不是更新缓存？
原因：
如果，在没有加锁的情况下，线程1执行完a后，时间片到，线程2开始执行b操作，执行完后，数据库的中name中a2值覆盖掉了a1。之后线程2继续执行d操作，后线程1执行c操作，执行问候，redis中的数据a1覆盖掉了a2，最终导致数据库和缓存数据不一致。解决方案是更新数据库和更新缓存加分布式锁操作，但是会影响效率。
而当我们使用删除操作时，可以不用担心这类问题。
更新缓存在并发下会带来种种问题，直接删除缓存比较简单粗暴，稳妥。而且还有懒加载的思想，等用到的时候在去数据库读出来放进去，不用到你每次去更新他干嘛，浪费时间资源，而且还有更新失败、产生脏数据的一些风险， 达成这一点共识以后，我们来开始今天的讨论。
# 先更新数据库，再删除缓存
1、更新数据库成功，删除缓存成功，没问题。
2、更新数据库失败，程序捕获异常，不会走到下一步，不会出现数据不一致情况。
3、更新数据库成功，删除缓存失败。数据库是新数据，缓存是旧数据，发生了不一致的情况。这里我们来看下怎么解决：
- 重试的机制，如果删除缓存失败，我们捕获这个异常，把需要删除的key发送到消息队列， 然后自己创建一个消费者消费，尝试再次删除这个 key。（会对业务代码造成侵入）
- 异步更新缓存，更新数据库时会往 binlog 写入日志，所以我们可以通过一个服务来监听 binlog的变化（比如阿里的 canal），然后在客户端完成删除 key 的操作。如果删除失败的话，再发送到消息队列。
总之，对后删除缓存失败的情况，我们的做法是不断地重试删除，直到成功，达到最终一致性！
存在数据不一致的极短的窗口
不一致情况，解决方案：延迟双删
# 先删除缓存，再更新数据库
1、删除缓存成功，更新数据库成功 ，没问题。
2、删除缓存失败，程序捕获异常，不会走到下一步，不会出现数据不一致情况。
3、删除缓存成功，更新数据库失败，此时数据库中是旧数据，缓存中是空的，那么数据不会出现不一致。
虽然没有发生数据不一致的情况，看起来好像没问题，但是以上是在单线程的情况下，如果在并发的情况下可能会出现以下场景：
1）线程 A 需要更新数据，首先删除了 Redis 缓存
2）线程 B 查询数据，发现缓存不存在，到数据库查询旧值，写入 Redis，返回
3）线程 A 更新了数据库
2
3
这个时候，Redis是旧的值，数据库是新的值，还是发生了数据不一致的情况。
不一致的窗口不确定
现在我们再来分析一下 Cache Aside Pattern 的缺陷。
缺陷 1：首次请求数据一定不在 cache 的问题
解决办法：可以将热点数据可以提前放入 cache 中。
缺陷 2：写操作比较频繁的话导致 cache 中的数据会被频繁被删除，这样会影响缓存命中率 。
解决办法：
- 数据库和缓存数据强一致场景：更新 db 的时候同样更新 cache，不过我们需要加一个锁/分布式锁来保证更新 cache 的时候不存在线程安全问题。
- 可以短暂地允许数据库和缓存数据不一致的场景：更新 db 的时候同样更新 cache，但是给缓存加一个比较短的过期时间，这样的话就可以保证即使数据不一致的话影响也比较小。
# 延时双删
为了解决上面这种情况，我们有一种延时双删的策略，删一次不放心，隔一段时间再删一次。
1）删除缓存
2）更新数据库
3）休眠 500ms（这个时间，依据读取数据的耗时而定）
4）再次删除缓存
2
3
4
伪代码如下：
public void write(String key,Object data){
redis.delKey(key);
db.updateData(data);
Thread.sleep(500);
redis.delKey(key);
}
2
3
4
5
6
# 内存队列
除了延时双删这个方法，还有个方案就是内存队列，他的思想是串行化，但是这样的话吞吐量太低了，影响性能以及增加系统的复杂度，只是提供一个思路。
当更新数据的时候，我们不直接操作数据库和缓存，而是把数据的Id放到内存队列；当读数据的时候发现数据不在缓存中，我们不去数据库查放到缓存中，而是把数据的Id放到内存队列。
后台会有一个线程消费内存队列里面的数据，然后一条一条的执行。这样的话，一个更新数据的操作，先删除缓存，然后再去更新数据库，但是还没完成更新。此时如果一个读请求过来，读到了空的缓存，那么先将缓存更新的请求发送到队列中，此时会在队列中积压，然后同步等待缓存更新完成。
这里有一个优化点，一个队列中，其实多个更新缓存请求串在一起是没意义的，因此可以做过滤，如果发现队列中已经有一个更新缓存的请求了，那么就不用再放个更新请求操作进去了，直接等待前面的更新操作请求完成即可。
等内存队列中将更新数据的操作完成之后，才会去执行下一个操作，也就是读数据的操作，此时会从数据库中读取最新的值，然后写入缓存中。 如果请求还在等待时间范围内，不断轮询发现可以取到值了，那么就直接返回；如果请求等待的时间超过一定时长，那么这一次直接从数据库中读取。
# Read/Write Through Pattern（读写穿透）
Read/Write Through Pattern 中服务端把 cache 视为主要数据存储，从中读取数据并将数据写入其中。cache 服务负责将此数据读取和写入 db，从而减轻了应用程序的职责。
这种缓存读写策略小伙伴们应该也发现了在平时在开发过程中非常少见。抛去性能方面的影响，大概率是因为我们经常使用的分布式缓存 Redis 并没有提供 cache 将数据写入 db 的功能。
写（Write Through）：
- 先查 cache，cache 中不存在，直接更新 db。
- cache 中存在，则先更新 cache，然后 cache 服务自己更新 db（同步更新 cache 和 db）。
简单画了一张图帮助大家理解写的步骤。
读(Read Through)：
- 从 cache 中读取数据，读取到就直接返回 。
- 读取不到的话，先从 db 加载，写入到 cache 后返回响应。
简单画了一张图帮助大家理解读的步骤。
Read-Through Pattern 实际只是在 Cache-Aside Pattern 之上进行了封装。在 Cache-Aside Pattern 下，发生读请求的时候，如果 cache 中不存在对应的数据，是由客户端自己负责把数据写入 cache，而 Read Through Pattern 则是 cache 服务自己来写入缓存的，这对客户端是透明的。
和 Cache Aside Pattern 一样， Read-Through Pattern 也有首次请求数据一定不再 cache 的问题，对于热点数据可以提前放入缓存中。
# Write Behind Pattern（异步缓存写入）
Write Behind Pattern 和 Read/Write Through Pattern 很相似，两者都是由 cache 服务来负责 cache 和 db 的读写。
但是，两个又有很大的不同：Read/Write Through 是同步更新 cache 和 db，而 Write Behind 则是只更新缓存，不直接更新 db，而是改为异步批量的方式来更新 db。
很明显，这种方式对数据一致性带来了更大的挑战，比如 cache 数据可能还没异步更新 db 的话，cache 服务可能就就挂掉了。
这种策略在我们平时开发过程中也非常非常少见，但是不代表它的应用场景少，比如消息队列中消息的异步写入磁盘、MySQL 的 Innodb Buffer Pool 机制都用到了这种策略。
Write Behind Pattern 下 db 的写性能非常高，非常适合一些数据经常变化又对数据一致性要求没那么高的场景，比如浏览量、点赞量。
# 总结
上面说的几种方案，都是比较常见的，也比较简单，没有十全十美的，最后的延时双删和内存队列是为了解决先删除缓存，再更新数据库在并发下产生的问题。
今天讨论的Redis和数据库的数据更新是不可能通过事务达到统一的，我们只能根据相应的场景和所需要付出的代价来采取一些措施，降低数据不一致的问题出现的概率，在数据一致性和性能之间取得一个权衡，具体场景具体使用。