数据库跟缓存的双写一致性

忘是亡心i 2022-11-14 14:43 138阅读 0赞

号没留言功能，所以我建了个微信交流群来方便交流，现在需要你的加入，群里大佬贼多！目前入群满百发红包，**给个一起吹比的机会把阿Sir**，期待与你一起**相互吹捧，共同进步**。

![ec24b3d17d517cdb5b1f239ccb8f7a3f.png][]

# 1 关于一致性    #

为加速系统性能一般都会引入缓存机制，比如 [Redis][]。这种情况下当用户`读`数据时一般会按照如下流程：

![读流程][0d997d97651b6d8362bd73fc31a03bad.png] 读流程  
关于读的流程大家是没有异议的，但是对于数据的更新呢，如何操作才算合理呢？

1.  先更新数据库再更新缓存。
2.  先删缓存再更新数据库。
3.  先更新数据库再删缓存。

# 2 一致性解决方法 #

### 2.1 缓存TTL ###

简单直接又暴力的方法，如果有些数据不重要，我们读完一次数据到缓存后设置个TTL即可，等待超时后缓存自动从数据库读取下数据。

### 2.2 先更新数据库 再更新缓存 ###

假如我们有A、B两个请求，A请求将age = 14，B请求将age = 12。我们看下正常执行跟非正常执行情况：

![缓存旧数据][a60f6b364f935a14e91c469aa29c3c15.png] 缓存旧数据  
可发现如果出现网络震荡会导致缓存的数据是旧数据。因此这种方法不可取。并且如果是如下场景也不合适：

1.  写场景多而读场景少的业务需求，此时缓存不是经常性的读，却被频繁的更新。
2.  如果缓存的数据是经过各种复杂计算后写入的，那每次写入缓存都要运算一次，此法不可取。

### 2.3 先删缓存 再更新数据库 ###

假如A先请求更改数据，B请求读数据，如果因为网络导致发生如下情况也会造成缓存脏数据，如果此时缓存没有设置TTL那会一直是脏数据。

![缓存脏数据][72ff6c2f2a399c051f3942520ff61f05.png] 缓存脏数据  
上面这种情况如何解决呢？一般可以采用 `延时双删策略`，他的核心执行流程如下：

public  void write(String key,Object value){
        redis.delKey(key);
        db.updateValue(value);
        Thread.sleep(1000); // 再次删除
        redis.delKey(key);
    }

该思路落实到流程图上如下所示：

![延时双删策略][e3b770ac7b2664e8ed6a8f1efd36f828.png] 延时双删策略  
sleep的时间要根据业务数据逻辑耗时而定，反正目的是 `确保读请求结束，写请求可以删除读请求造成的缓存脏数据`。

当然如果用的是主从写读架构，那处理思路跟上面类似，无非就是休眠时间再加上主从同步的时间即可。

![主从模式二次删除][c2ade63233a69d8a499044c34550749a.png] 主从模式二次删除  
可是其实第二次删除还是有不妥的地方：

1.  二次删除前面涉及到休眠，可能导致系统性能降低，可以采用**异步**的方式，再起一个线程来进行异步删除。
2.  如果二次删除失败了，还是会导致缓存脏数据存在的啊！

### 2.4 先更新数据库 再删缓存 ###

针对缓存更新问题，老外提出了一个名为《Cache-Aside pattern》的缓存更新套路，该策略在Facebook中也广泛使用，该策略指出：

1.  **`失效`**：应用程序先从缓存取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。
2.  **`命中`**：应用程序从缓存中取数据，取到后返回。
3.  **`更新`**：先把数据存到数据库中，成功后，再让缓存失效。

假如此时A、B两个线程同时请求，正常来讲不管你是读写分离还是单机版，读一般比写快。那删除缓存一般是有效的。

![先更新数据库再删除缓存][b4f46776b32bee61ae0f4eb40b8f9486.png] 先更新数据库再删除缓存  
但是也有可能别的原因导致读比写还慢，导致我们删了个 **寂寞**，虽然这种情况很少发生。  
![读比写还慢时][cefc8a19af4cecca8f7f57ab9b037c7c.png] 读比写还慢时  
该方案相比先删除缓存再更新数据库还是稳妥些的，但是也不是万无一失的。不管是先删缓存再更新数据库还是先更新数据库再删缓存， `如果删除缓存失败了都会导致缓存跟数据不一致问题`！

### 2.5 消息队列 确保消息删除 ###

通过消息队列的确认消费机制来删除缓存。

![消息队列机制确保删除][81a9557e2374b3e104277d04510fcae8.png] 消息队列机制确保删除  
缺点也很明显：

1.  对业务线代码造成大量的侵入，引入了中间件。
2.  消息的延迟删除也会造成短暂的不一致。

### 2.6 专门程序+消息队列 确保消息删除 ###

该方案启动一个订阅程序去订阅数据库的binlog，获得需要操作的数据。在应用程序中，另起一段程序，获得这个订阅程序传来的信息，进行删除缓存操作。

![专门程序删除缓存][d4f2400c446556b6870403e74ac992fa.png] 专门程序删除缓存  
订阅binlog程序在mysql中有现成的中间件叫 **canal**，可以完成订阅binlog日志的功能。

# 3 总结 #

分析后你会发现数据更新时`缓存是删除不是更新`，而删除缓存一般有三种方法：

1.  如果缓存数据不敏感，直接给缓存设置TTL即可。
2.  先删缓存再更新数据库，此时需配合延时双删技术，但可能导致二次删除失败。
3.  先更新数据库再删缓存，此时需配合binlog消费 + 消息队列来实现。

# 4 参考 #

1.  Java后端：http://rjzheng.cnblogs.com
2.  艾小仙分布式锁：https://t.1yb.co/jaaA

[ec24b3d17d517cdb5b1f239ccb8f7a3f.png]: /images/20221022/6045955f2011473287a916e7c3ce64fe.png
[Redis]: https://mp.weixin.qq.com/s?__biz=MzI4NjI1OTI4Nw%3D%3D&idx=1&mid=2247488832&scene=21&sn=5999893d7fe773f54f7d097ac1c2074d#wechat_redirect
[0d997d97651b6d8362bd73fc31a03bad.png]: /images/20221022/ab8b0436ecbf46888fe9b4d63361f0c6.png
[a60f6b364f935a14e91c469aa29c3c15.png]: /images/20221022/27993a605890414eaa7f7bfbb57804df.png
[72ff6c2f2a399c051f3942520ff61f05.png]: /images/20221022/655f64072ab7499ebde42282537a50b4.png
[e3b770ac7b2664e8ed6a8f1efd36f828.png]: /images/20221022/7008fde8adb249f2a16c665b7f52736b.png
[c2ade63233a69d8a499044c34550749a.png]: /images/20221022/1a999351a2294eb381d8b37c230cd79b.png
[b4f46776b32bee61ae0f4eb40b8f9486.png]: /images/20221022/04c9c5210fd24d71acb074aecabdf570.png
[cefc8a19af4cecca8f7f57ab9b037c7c.png]: /images/20221022/efa9ac4d3eb74278a3aeb12bb57ae996.png
[81a9557e2374b3e104277d04510fcae8.png]: /images/20221022/b09cb256d02f4bb19df9ec54145236dd.png
[d4f2400c446556b6870403e74ac992fa.png]: /images/20221022/48d98af443aa46b6ad32495820d058d7.png