数据一致性的一些思考

一时失言乱红尘 2022-11-05 00:55 21阅读 0赞

# 结论 #

没有银弹，需要根据自己的业务场景做取舍。

*  业务量有多少，需要主从读写分离么，需要分库分表么？
 *  是读多还是写多？
 *  是要最终一致性，还是强一致性？
 *  对缓存一致性的要求是多少？1分钟？一秒钟？
 *  查询结构是怎样的。是需要多表合并，还是多行合并，还是多库合并？
 *  该如何容灾?更新、删除缓存失败你能不能接受？写数据库失败怎么办？
 *  如果删除缓存失败，你还允不允许更新数据库？

要根据实际业务场景来定制方案。

# DB主从一致 #

大部分业务场景都是读多写少，而且数据库（mysql）写很少看到写挂的，都是读有瓶颈。  
所以主从读写分离就出现了，写的时候写主库，然后同步到从库，读的时候就读从库。

那么，很明显从库不是最新数据，就会有不一致的情况。

为了解决主从数据库读取旧数据的问题，常用的方案有四种：

（1）半同步复制  
（2）强制读主  
（3）数据库中间件  
（4）缓存记录写key

## 解决方案1：半同步复制 ##

> 不一致是因为写完成后，主从同步有一个时间差，假设是500ms，这个时间差有读请求落到从库上产生的。有没有办法做到，等主从同步完成之后，主库上的写请求再返回呢？

答案是肯定的，就是大家常说的“半同步复制”semi-sync：  
（1）系统先对DB-master进行了一个写操作，写主库  
（2）等主从同步完成，写主库的请求才返回  
（3）读从库，读到最新的数据（如果读请求先完成，写请求后完成，读取到的是“当时”最新的数据）

方案优点：利用数据库原生功能，比较简单  
方案缺点：主库的写请求时延会增长，吞吐量会降低

## 解决方案2：强制读主库 ##

如果不使用“增加从库”的方式来增加提升系统的读性能，完全可以读写都落到主库，这样就不会出现不一致了：

方案优点：“一致性”上不需要进行系统改造  
方案缺点：只能通过cache来提升系统的读性能。

## 解决方案3：数据库中间件 ##

如果有了数据库中间件，所有的数据库请求都走中间件，这个主从不一致的问题可以这么解决：

（1）所有的读写都走数据库中间件，通常情况下，写请求路由到主库，读请求路由到从库  
（2）记录所有路由到写库的key，在经验主从同步时间窗口内（假设是500ms），如果有读请求访问中间件，此时有可能从库还是旧数据，就把这个key上的读请求路由到主库  
（3）经验主从同步时间过完后，对应key的读请求继续路由到从库

方案优点：能保证绝对一致  
方案缺点：数据库中间件的成本比较高

## 解决方案4：缓存记录写key法 ##

既然数据库中间件的成本比较高，有没有更低成本的方案来记录某一个库的某一个key上发生了写请求呢？很容易想到使用缓存，当写请求发生的时候：

（1）将某个库上的某个key要发生写操作，记录在cache里，并设置“经验主从同步时间”的cache超时时间，例如500ms  
（2）修改数据库

而读请求发生的时候：

（1）先到cache里查看，对应库的对应key有没有相关数据  
（2）如果cache hit，有相关数据，说明这个key上刚发生过写操作，此时需要将请求路由到主库读最新的数据  
（3）如果cache miss，说明这个key上近期没有发生过写操作，此时将请求路由到从库，继续读写分离

方案优点：相对数据库中间件，成本较低  
方案缺点：为了保证“一致性”，引入了一个cache组件，并且读写数据库时都多了一步cache操作

# 数据库和缓存 最终一致性方案 #

数据库和缓存由于是异步更新，所以必然会有不一致的情况，要根据自己的业务场景去抉择。

根本原因：

> 操作数据库慢，操作缓存快。

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

## 第一种：先更新数据库，再更新缓存 ##

### 并发问题 ###

（1）线程A更新了数据库  
（2）线程B更新了数据库  
（3）线程B更新了缓存  
（4）线程A更新了缓存  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhcHB5X3RlZW1v_size_16_color_FFFFFF_t_70]

#### 解决：序列化达到最终一致 ####

序列化，用一个消息队列顺序刷新缓存。会达到最终一致性  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhcHB5X3RlZW1v_size_16_color_FFFFFF_t_70 1]

#### 优缺点 ####

好处：

*  不存在并发写库的问题。
 *  写流程容灾分析
    
     *  写1.1 DEL缓存失败：没关系，后面会覆盖
     *  写1.4 写MQ失败：没关系，Databus或Canal都会重试
     *  消费MQ的：1.5 || 1.6 失败：没关系，重新消费即可
 *  读流程容灾分析
    
     *  读2.3 异步写MQ失败：没关系，缓存为空，是OK的，下次还读库就好了

缺点：

*  会有一点延迟
 *  会有ABA的问题，比如关注–取关–关注，操作的人再刷新可能还是未关注（缓存停留在第二步）。

## 第二种：先删缓存，再更新数据库 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhcHB5X3RlZW1v_size_16_color_FFFFFF_t_70 2]

### 并发问题 ###

（1）请求A进行写操作，删除缓存  
（2）请求B查询发现缓存不存在  
（3）请求B去数据库查询得到旧值  
（4）请求A将新值写入缓存  
（5）请求B将旧值写入缓存（覆盖了）

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhcHB5X3RlZW1v_size_16_color_FFFFFF_t_70 3]

#### 解决 ：延时双删 ####

在上面的基础上加上一个延时，再更新一次。  
（6）延时一段时间，请求A将新值写入缓存（再次覆盖）

#### 优缺点 ####

*  优点
    
     *  实现简单
     *  通常不会有错误数据（删缓存很少有问题，而更新缓存肯定涉及到逻辑，可能会有bug）
     *  异步刷新，补缺补漏 (如果删缓存有问题，后面会有更新缓存顶上)
 *  缺点
    
     *  如果删和更新都失败，这个脏数据会停留比较长时间。（缓存设置过期时间不就行了？）
     *  并发问题难以完美解决。

## 第三种：先更新数据库，再删缓存 ##

由于数据库比缓存慢，所以更新完数据库再更新缓存，不一致的时间的较短的。

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhcHB5X3RlZW1v_size_16_color_FFFFFF_t_70 4]

### 并发问题 ###

（1）缓存刚好失效  
（2）请求A查询数据库，得一个旧值  
（3）请求B将新值写入数据库  
（4）请求B删除缓存  
（5）请求A将查到的旧值写入缓存

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhcHB5X3RlZW1v_size_16_color_FFFFFF_t_70 5]  
这种情况需要满足：

*  缓存刚好失效的时候有人写库。
 *  写库比读库快。

#### 解决 ####

首先，给缓存设有效时间是一种方案。  
其次，采用异步延时删除策略，保证读请求完成以后，再进行删除操作也可以。

## 第四种：先更新缓存，再更新数据库 ##

应该没人会选择吧。

更新数据库失败了，脏缓存咋办。。。

## 对于删缓存失败的解决方案 ##

### 方案一： ###

如下图所示

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhcHB5X3RlZW1v_size_16_color_FFFFFF_t_70 6]

流程如下所示

（1）更新数据库数据；  
（2）缓存因为种种问题删除失败  
（3）将需要删除的key发送至消息队列  
（4）自己消费消息，获得需要删除的key  
（5）继续重试删除操作，直到成功 然而，该方案有一个缺点，对业务线代码造成大量的侵入。

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

### 方案二： ###

流程如下图所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhcHB5X3RlZW1v_size_16_color_FFFFFF_t_70 7]

（1）更新数据库数据  
（2）数据库会将操作信息写入binlog日志当中  
（3）订阅程序提取出所需要的数据以及key  
（4）另起一段非业务代码，获得该信息  
（5）尝试删除缓存操作，发现删除失败  
（6）将这些信息发送至消息队列  
（7）重新从消息队列中获得该数据，重试操作。

备注说明：上述的订阅binlog程序在mysql中有现成的中间件叫canal，可以完成订阅binlog日志的功能。如果对一致性要求不是很高，直接在程序中另起一个线程，每隔一段时间去重试即可，这些大家可以灵活自由发挥，只是提供一个思路。

# 数据库和缓存强一致性方案 #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhcHB5X3RlZW1v_size_16_color_FFFFFF_t_70 8]  
强一致性，包含两种含义：

> 缓存和DB数据一致  
> 缓存中没有数据（或者说：不会去读缓存中的老版本数据）

首先我们来分析一下，既然已经实现了“最终一致性”，那它和“强一致性”的区别是什么呢？

没错，就是“时间差”，所以：

> “最终一致性方案” + “时间差” = “强一致性方案”

那我们的工作呢，就是加上时间差，  
**实现方式：我们加一个缓存，将近期被修改的数据进行标记锁定。  
读的时候，标记锁定的数据强行走DB，没锁定的数据，先走缓存**

## 优缺点 ##

### 容灾完善 ###

写流程容灾分析

*  写1.1 标记失败：没关系，放弃整个更新操作
 *  写1.3 DEL缓存失败：没关系，后面会覆盖
 *  写1.5 写MQ失败：没关系，Databus或Canal都会重试
 *  消费MQ的：1.6 || 1.7 失败：没关系，重新消费即可

读流程容灾分析

*  读2.1 读Cache\_0失败：没关系，直接读主库
 *  读2.3 异步写MQ失败：没关系，缓存为空，是OK的，下次还读库就好了

### 无并发问题 ###

这个方案让“读库 + 刷缓存”的操作串行化，这就不存在老数据覆盖新数据的并发问题了

### 缺点剖析 ###

1.  增加Cache\_0强依赖  
    这个其实有点没办法，你要强一致性，必然要牺牲一些的。  
    但是呢，你这个可以吧Cache\_0设计成多机器多分片，这样的话，即使部分分片挂了，也只有小部分流量透过Cache直接打到DB上，这是完全是可接受的
2.  复杂度是比较高的
3.  吞吐量大大降低。

# 总结 #

常规最终一致性解决方案：

*  读先读缓存，缓存不在，读库。
 *  写库写队列，或者订阅biglog，然后回刷缓存。

## 参考 ##

https://blog.kido.site/2018/12/01/db-and-cache-01/  
https://www.cnblogs.com/rjzheng/p/9041659.html  
https://blog.kido.site/2018/12/09/db-and-cache-04/  
https://zhuanlan.zhihu.com/p/59167071

## 相关阅读： ##

*  [【微服务理论】01.微服务概览][01.]
 *  [【微服务理论】听说你不知道康威定律？][Link 1]
 *  [【微服务理论】API + BFF 不再为兼容和适配烦恼][API _ BFF]
 *  [【微服务理论】微服务该怎么划分][Link 2]
 *  [数据一致性的一些思考][Link 3]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhcHB5X3RlZW1v_size_16_color_FFFFFF_t_70]: /images/20221023/c3b6443797c94fb59efeabae077dd05b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhcHB5X3RlZW1v_size_16_color_FFFFFF_t_70 1]: /images/20221023/7ec9ea71ed304f3b9b33da224cdd27b6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhcHB5X3RlZW1v_size_16_color_FFFFFF_t_70 2]: /images/20221023/cb3a95d8a8f0407eab202dd66236b148.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhcHB5X3RlZW1v_size_16_color_FFFFFF_t_70 3]: /images/20221023/d3008e4dd061422b99108fd268e40ea9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhcHB5X3RlZW1v_size_16_color_FFFFFF_t_70 4]: /images/20221023/4b63edd8f110438fb7d7fbd4bc45c035.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhcHB5X3RlZW1v_size_16_color_FFFFFF_t_70 5]: /images/20221023/53a1957476a6440d91769091ce6b18b2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhcHB5X3RlZW1v_size_16_color_FFFFFF_t_70 6]: /images/20221023/b4038009f60c43608924a45dd7c29cb9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhcHB5X3RlZW1v_size_16_color_FFFFFF_t_70 7]: /images/20221023/7c71ee96af974d548336a438b0ace891.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hhcHB5X3RlZW1v_size_16_color_FFFFFF_t_70 8]: /images/20221023/efb6aa7116564a6e91db70a10cc189a5.png
[01.]: https://happyteemo.blog.csdn.net/article/details/113078074
[Link 1]: https://happyteemo.blog.csdn.net/article/details/113088894
[API _ BFF]: https://happyteemo.blog.csdn.net/article/details/113087226
[Link 2]: https://happyteemo.blog.csdn.net/article/details/113139668
[Link 3]: https://happyteemo.blog.csdn.net/article/details/114321822