DB主从一致性架构优化4种方法

刺骨的言语ヽ痛彻心扉 2022-05-31 07:11 101阅读 0赞

需求缘起

大部分互联网的业务都是“读多写少”的场景，数据库层面，读性能往往成为瓶颈。如下图：业界通常采用“一主多从，读写分离，冗余多个读库”的数据库架构来提升数据库的读性能。

![70][]

（1）系统先对DB-master进行了一个写操作，写主库

（2）很短的时间内并发进行了一个读操作，读从库，此时主从同步没有完成，故读取到了一个旧数据

（3）主从同步完成

有没有办法解决或者缓解这类“由于主从延时导致读取到旧数据”的问题呢，这是本文要集中讨论的问题。

方案一（半同步复制）

不一致是因为写完成后，主从同步有一个时间差，假设是500ms，这个时间差有读请求落到从库上产生的。有没有办法做到，等主从同步完成之后，主库上的写请求再返回呢？答案是肯定的，就是大家常说的“半同步复制”semi-sync：

![70 1][]  
（1）系统先对DB-master进行了一个写操作，写主库

（2）等主从同步完成，写主库的请求才返回

（3）读从库，读到最新的数据（如果读请求先完成，写请求后完成，读取到的是“当时”最新的数据）

方案优点：利用数据库原生功能，比较简单

方案缺点：主库的写请求时延会增长，吞吐量会降低

方案二（强制读主库）

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

![70 2][]  
方案优点：“一致性”上不需要进行系统改造

方案缺点：只能通过cache来提升系统的读性能，这里要进行系统改造

方案三（数据库中间件）

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

![70 3][]  
（1）所有的读写都走数据库中间件，通常情况下，写请求路由到主库，读请求路由到从库

（2）记录所有路由到写库的key，在经验主从同步时间窗口内（假设是500ms），如果有读请求访问中间件，此时有可能从库还是旧数据，就把这个key上的读请求路由到主库

（3）经验主从同步时间过完后，对应key的读请求继续路由到从库

方案优点：能保证绝对一致

方案缺点：数据库中间件的成本比较高

方案四（缓存记录写key法）

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

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

（2）修改数据库

而读请求发生的时候：

![70 5][]  
（1）先到cache里查看，对应库的对应key有没有相关数据

（2）如果cache hit，有相关数据，说明这个key上刚发生过写操作，此时需要将请求路由到主库读最新的数据

（3）如果cache miss，说明这个key上近期没有发生过写操作，此时将请求路由到从库，继续读写分离

方案优点：相对数据库中间件，成本较低

方案缺点：为了保证“一致性”，引入了一个cache组件，并且读写数据库时都多了一步cache操作

总结

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

（1）半同步复制

（2）强制读主

（3）数据库中间件

（4）缓存记录写key

[70]: /images/20220531/dc184d9dee044e2ba48a0fe2437cb71d.png
[70 1]: /images/20220531/1aac8cab0d2843529408597f4b80f024.png
[70 2]: /images/20220531/6edb3d3841f24ddcb3df237944b84931.png
[70 3]: /images/20220531/2c970c472edb45a6aaeee85684e41528.png
[70 4]: /images/20220531/82946a1264244801929b2738dd68b63c.png
[70 5]: /images/20220531/5484a75e7f6f40089ae4f63c1d430190.png

发表评论取消回复

表情：

评论列表（有 0 条评论，101人围观）

还没有评论，来说两句吧...

相关阅读

相关 redis,db,mq一致性

edis和db update: 删除Redis --> 更新DB --> 下次查询同步更新Redis。删除Redis失败不会更新db 2、复杂情况：删Red...

小咪咪/ 2024年04月18日 18:16/ 0 赞/ 46 阅读

相关 mysql主从一致性保证

MySQL实战问题03 mysql如何保证主备一致 MySQL主备的基本原理主备流程切换在状态1中，客户端的读写都直接访问节点A，而节点B是A的备库，只是将A的更新都

怼烎@/ 2023年09月25日 09:45/ 0 赞/ 55 阅读

相关 C/C++冒泡排序4种优化方法

冒泡排序应该是大多数人接触的第一种排序方法，虽然它的时间复杂度为O（n^2），但是它简单易懂，代码复杂度低，所以仍有很大的用武之地。最近在总结排序算法，决定重温下冒泡排序，以及

怼烎@/ 2022年11月17日 14:44/ 0 赞/ 127 阅读

相关 DB主从一致性架构优化4种方法

转自：http://oicwx.com/detail/962358 需求缘起大部分互联网的业务都是“读多写少”的场景，数据库层面，读性能往往成为瓶颈。如下图：业界通常采用

一时失言乱红尘/ 2022年09月27日 00:26/ 0 赞/ 84 阅读

相关 redis主从架构(4)

1、redis高并发跟整个系统的高并发之间的关系 redis，你要搞高并发的话，不可避免，要把底层的缓存搞得很好 mysql，高并发，做到了，那么也是通过一系列复杂的分

绝地灬酷狼/ 2022年06月01日 07:18/ 0 赞/ 184 阅读

相关 DB主从一致性架构优化4种方法

需求缘起大部分互联网的业务都是“读多写少”的场景，数据库层面，读性能往往成为瓶颈。如下图：业界通常采用“一主多从，读写分离，冗余多个读库”的数据库架构来提升数据库的读性能。

刺骨的言语ヽ痛彻心扉/ 2022年05月31日 07:11/ 0 赞/ 102 阅读

相关主从DB与Cache一致性优化

原文地址：https://mp.weixin.qq.com/s?\_\_biz=MjM5ODYxMDA5OQ==&mid=404308725&idx=1&sn=1a25ce76

Dear 丶/ 2022年05月21日 01:12/ 0 赞/ 130 阅读

相关 Java架构师面试题——数据库主从同步的3种一致性方案实现，及优劣比较

数据主从同步的由来互联网的很多业务，特别是在高并发的场景下，基本都是读远远大于写，如果数据库读和写的压力都同在一台主机上，这显然不太合理。于是，把一台数据库主

迷南。/ 2022年03月08日 13:18/ 0 赞/ 458 阅读

相关高并发架构系列：数据库主从同步的3种一致性方案实现，及优劣比较

数据主从同步的由来互联网的很多业务，特别是在高并发的场景下，基本都是读远远大于写，如果数据库读和写的压力都同在一台主机上，这显然不太合理。于是，把一台数据库主

冷不防/ 2022年02月27日 06:08/ 0 赞/ 212 阅读

相关 mysql主从同步 binlog-do-db replicate-do-db

在主服务器上为从服务器建立一个用户： grant replication slave on \.\ to '用户名'@'主机' identified by '密码'; 如果

朴灿烈づ我的快乐病毒、/ 2021年06月24日 14:37/ 0 赞/ 469 阅读