如何保证缓存与数据库双写时的数据一致性？

我会带着你远行 2022-09-16 00:17 262阅读 0赞

点击上方蓝色“石杉的架构笔记”，选择“设为星标”

回复“PDF”获取独家整理的学习资料！

![1023ce0221f813aef8a9cd9f9395d041.png][]

![ad8fb6480a2e620fd29bf34f514244ff.png][]

代码托管仓库：https://gitee.com/suzhou-mopdila-information/ruyuan-dfs

![22ee26c2931cfbd6c8fff23061d0b8ed.png][]

长按扫描上方免费参加

![741b929f2943575996ec7ea9810d499d.png][]

来源：https://www.jianshu.com/p/a8eb1412471f

**| 背景**

在做系统优化时，想到了将数据进行分级存储的思路。因为在系统中会存在一些数据，有些数据的实时性要求不高，比如一些配置信息。

基本上配置了很久才会变一次。而有一些数据实时性要求非常高，比如订单和流水的数据。所以这里根据数据要求实时性不同将数据分为三级。

*  第1级：订单数据和支付流水数据；这两块数据对实时性和精确性要求很高，所以不添加任何缓存，读写操作将直接操作数据库。
 *  第2级：用户相关数据；这些数据和用户相关，具有读多写少的特征，所以我们使用redis进行缓存。
 *  第3级：支付配置信息；这些数据和用户无关，具有数据量小，频繁读，几乎不修改的特征，所以我们使用本地内存进行缓存。

但是只要使用到缓存，无论是本地内存做缓存还是使用 redis 做缓存，那么就会存在数据同步的问题，因为配置信息缓存在内存中，而内存时无法感知到数据在数据库的修改。这样就会造成数据库中的数据与缓存中数据不一致的问题。

接下来就讨论一下关于保证缓存和数据库双写时的数据一致性。

## **| 解决方案** ##

那么我们这里列出来所有策略，并且讨论他们优劣性。

1.  先更新数据库，后更新缓存
2.  先更新数据库，后删除缓存
3.  先更新缓存，后更新数据库
4.  先删除缓存，后更新数据库

### **| 先更新数据库，后更新缓存** ###

这种场景一般是没有人使用的，主要原因是在更新缓存那一步，为什么呢？因为有的业务需求缓存中存在的值并不是直接从数据库中查出来的，有的是需要经过一系列计算来的缓存值，那么这时候后你要更新缓存的话其实代价是很高的。如果此时有大量的对数据库进行写数据的请求，但是读请求并不多，那么此时如果每次写请求都更新一下缓存，那么性能损耗是非常大的。

举个例子比如在数据库中有一个值为 1 的值，此时我们有 10 个请求对其每次加一的操作，但是这期间并没有读操作进来，如果用了先更新数据库的办法，那么此时就会有十个请求对缓存进行更新，会有大量的冷数据产生，如果我们不更新缓存而是删除缓存，那么在有读请求来的时候那么就会只更新缓存一次。

### **| 先更新缓存，后更新数据库** ###

这一种情况应该不需要我们考虑了吧，和第一种情况是一样的。

### **|先删除缓存，后更新数据库** ###

该方案也会出问题，具体出现的原因如下。

![aa5ff342cad2acd47f3282fb05ab3dcd.png][] 先删除缓存，后更新数据库

此时来了两个请求，请求 A（更新操作） 和请求 B（查询操作）。

1.  请求 A 会先删除 Redis 中的数据，然后去数据库进行更新操作。
2.  此时请求 B 看到 Redis 中的数据时空的，会去数据库中查询该值，补录到 Redis 中。
3.  但是此时请求 A 并没有更新成功，或者事务还未提交。

那么这时候就会产生数据库和 Redis 数据不一致的问题。如何解决呢？其实最简单的解决办法就是延时双删的策略。

![79f6fa9beeed7b04f4fcc3a974d9ac7a.png][] 延时双删

但是上述的保证事务提交完以后再进行删除缓存还有一个问题，就是如果你使用的是 Mysql 的读写分离的架构的话，那么其实主从同步之间也会有时间差。

![e3abc8ae065fd2ee6b02890410691991.png][] 主从同步时间差

此时来了两个请求，请求 A（更新操作） 和请求 B（查询操作）。

1.  请求 A 更新操作，删除了 Redis。
2.  请求主库进行更新操作，主库与从库进行同步数据的操作。
3.  请 B 查询操作，发现 Redis 中没有数据。
4.  去从库中拿去数据。
5.  此时同步数据还未完成，拿到的数据是旧数据。

此时的解决办法就是如果是对 Redis 进行填充数据的查询数据库操作，那么就强制将其指向主库进行查询。

![fec3cb296a4e91085f9b5b9212c8c302.png][] 从主库中拿数据

### **| 先更新数据库，后删除缓存** ###

问题：这一种情况也会出现问题，比如更新数据库成功了，但是在删除缓存的阶段出错了没有删除成功，那么此时再读取缓存的时候每次都是错误的数据了。

![67be1fd26afb7729237dafe622a86939.png][] 先更新数据库，后删除缓存

此时解决方案就是利用消息队列进行删除的补偿。具体的业务逻辑用语言描述如下：

1.  请求 A 先对数据库进行更新操作。
2.  在对 Redis 进行删除操作的时候发现报错，删除失败。
3.  此时将Redis 的 key 作为消息体发送到消息队列中。
4.  系统接收到消息队列发送的消息后再次对 Redis 进行删除操作。

但是这个方案会有一个缺点就是会对业务代码造成大量的侵入，深深的耦合在一起，所以这时会有一个优化的方案，我们知道对 Mysql 数据库更新操作后再 binlog 日志中我们都能够找到相应的操作，那么我们可以订阅 Mysql 数据库的 binlog 日志对缓存进行操作。

![f6b3bdbc34f95953eac83d974dfa27f1.png][]

利用订阅binlog 删除缓存

**| 总结 **

每种方案各有利弊，比如在第二种先删除缓存，后更新数据库这个方案我们最后讨论了要更新 Redis 的时候强制走主库查询就能解决问题，那么这样的操作会对业务代码进行大量的侵入，但是不需要增加的系统，不需要增加整体的服务的复杂度。

最后一种方案我们最后讨论了利用订阅 binlog 日志进行搭建独立系统操作 Redis，这样的缺点其实就是增加了系统复杂度。

其实每一次的选择都需要我们对于我们的业务进行评估来选择，没有一种技术是对于所有业务都通用的。没有最好的，只有最适合我们的。

![dbdb622a1d357c47c007d21fa890f9f3.png][]

![f7ac74f6f1720c6c8099b9d72359a2a6.png][]

![2f966fb5ed9ed53a659ac8d62a6e0d62.png][]

![5aa369cf6fd0bba95f714aca98ab42f0.png][]

![0ef3b44ae1eba6de3141b6f498e4d3e8.png][]

[1023ce0221f813aef8a9cd9f9395d041.png]: /images/20220828/16ba829770b5404bb3754ffb83488809.png
[ad8fb6480a2e620fd29bf34f514244ff.png]: /images/20220828/ba9600225d2040cabfe070724d9b9801.png
[22ee26c2931cfbd6c8fff23061d0b8ed.png]: /images/20220828/a13dd9f9442a408ca2c2d493b28a28c9.png
[741b929f2943575996ec7ea9810d499d.png]: /images/20220828/0d33577f5f1142c9a7d2b810abe8c7a8.png
[aa5ff342cad2acd47f3282fb05ab3dcd.png]: /images/20220828/84cf710b01224de8804f496e81792d61.png
[79f6fa9beeed7b04f4fcc3a974d9ac7a.png]: /images/20220828/d21476a094cf4bb9ac605d88c4699cdd.png
[e3abc8ae065fd2ee6b02890410691991.png]: /images/20220828/6da50d24d2434fa4b96e8877455675ee.png
[fec3cb296a4e91085f9b5b9212c8c302.png]: /images/20220828/88f768b8a0654faa9c16bdec70effe2d.png
[67be1fd26afb7729237dafe622a86939.png]: /images/20220828/061188eb6dd841e5865a796d3547013d.png
[f6b3bdbc34f95953eac83d974dfa27f1.png]: /images/20220828/f01ffc8c7f5c46d98f451ef4718b9691.png
[dbdb622a1d357c47c007d21fa890f9f3.png]: /images/20220828/a332550e84fe461eab9fe819364bed6b.png
[f7ac74f6f1720c6c8099b9d72359a2a6.png]: /images/20220828/25486a628977418288c4c0f7e2ecc321.png
[2f966fb5ed9ed53a659ac8d62a6e0d62.png]: /images/20220828/6dcedbc81b7a4767946fd63b1f33d9f7.png
[5aa369cf6fd0bba95f714aca98ab42f0.png]: /images/20220828/33e72a87003d40c98eddd2d87a3fc77a.png
[0ef3b44ae1eba6de3141b6f498e4d3e8.png]: /images/20220828/04ef1df94f8a47e8aa9782d8e10b5441.png