需求缘起

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


这种架构的一个潜在缺点是,业务方有可能读取到并不是最新的旧数据:


(1)系统先对DB-master进行了一个写操作,写主库

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

(3)主从同步完成

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

方案一(半同步复制)

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


(1)系统先对DB-master进行了一个写操作,写主库

(2)等主从同步完成,写主库的请求才返回

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

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

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

方案二(强制读主库)

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


方案优点:“一致性”上不需要进行系统改造

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

方案三(数据库中间件)

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


(1)所有的读写都走数据库中间件,通常情况下,写请求路由到主库,读请求路由到从库

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

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

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

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

方案四(缓存记录写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)缓存记录写key

前3个方案在今年数据库大会(DTCC2016)上share过,相关的材料在网上能下载到。第4个方案是大会现场有其他同学share的一个好方法,感谢这位同学。

【文章转载自微信公众号“架构师之路”】

【58沈剑架构系列】DB主从一致性架构优化4种方法的更多相关文章

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

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

  2. KA,连接池居然这么简单? 原创: 58沈剑 架构师之路 3月20日

    KA,连接池居然这么简单? 原创: 58沈剑 架构师之路 3月20日

  3. 线上服务内存OOM问题定位[转自58沈剑]

    相信大家都有感触,线上服务内存OOM的问题,是最难定位的问题,不过归根结底,最常见的原因: 本身资源不够 申请的太多 资源耗尽 58到家架构部,运维部,58速运技术部联合进行了一次线上服务内存OOM问 ...

  4. 顽石系列:CSS实现垂直居中的五种方法

    顽石系列:CSS实现垂直居中的五种方法 在开发过程中,我们可能沿用或者试探性地去使用某种方法实现元素居中,但是对各种居中方法的以及使用场景很不清晰.参考的内容链接大概如下: 行内元素:https:// ...

  5. 【58沈剑架构系列】主从DB与cache一致性

    本文主要讨论这么几个问题: (1)数据库主从延时为何会导致缓存数据不一致 (2)优化思路与方案 一.需求缘起 上一篇<缓存架构设计细节二三事>中有一个小优化点,在只有主库时,通过“串行化” ...

  6. 【58沈剑架构系列】mysql并行复制优化思路

    一.缘起 mysql主从复制,读写分离是互联网用的非常多的mysql架构,主从复制最令人诟病的地方就是,在数据量较大并发量较大的场景下,主从延时会比较严重. 为什么mysql主从延时这么大? 回答:从 ...

  7. 【58沈剑架构系列】RPC-client异步收发核心细节?

    第一章聊了[“为什么要进行服务化,服务化究竟解决什么问题”] 第二章聊了[“微服务的服务粒度选型”] 第三章聊了[“为什么说要搞定微服务架构,先搞定RPC框架?”] 上一章聊了[“微服务架构之RPC- ...

  8. 【58沈剑架构系列】微服务架构之RPC-client序列化细节

    第一章聊了[“为什么要进行服务化,服务化究竟解决什么问题”] 第二章聊了[“微服务的服务粒度选型”] 上一篇聊了[“为什么说要搞定微服务架构,先搞定RPC框架?”] 通过上篇文章的介绍,知道了要实施微 ...

  9. 【58沈剑架构系列】互联网公司为啥不使用mysql分区表?

    缘起:有个朋友问我分区表在58的应用,我回答不出来,在我印象中,百度.58都没有听说有分区表相关的应用,业内进行一些技术交流的时候也更多的是自己分库分表,而不是使用分区表.于是去网上查了一下,并询问了 ...

随机推荐

  1. 【莫队】【P3834】 【模板】可持久化线段树 1(主席树)

    大家好,我是个毒瘤,我非常喜欢暴力数据结构,于是我就用莫队+分块过了这个题 Solution 发现这个题静态查询资瓷离线,于是考虑莫队. 在这里简单介绍一下莫队: 将所有询问离线后,对原序列分块.按照 ...

  2. 手脱tElock 0.98b1 -> tE!

    声明: 只为纪录自己的脱壳历程,高手勿喷 第一种:两次内存法 注: ①这是在win7x32系统上运行的脱壳,所以可能地址不同 ②修复的时候用等级三修复,最后修复不了的剪切掉然后转存合一正常运行,已测试 ...

  3. 小程序navigatorTo缺点和修正方法

    1.不好带参数跳转到tabbar,即下部的导航栏目. reLauntch方法可以传递参数到导航栏目: go_to_prolist: function (e) { var datatype = e.cu ...

  4. vue 父子组件相互传递数据

    例子一 <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <meta ...

  5. zoj 2314 Reactor Cooling (无源汇上下界可行流)

    Reactor Coolinghttp://acm.zju.edu.cn/onlinejudge/showProblem.do?problemId=1314 Time Limit: 5 Seconds ...

  6. Python学习笔记(三十一)正则表达式

    ---恢复内容开始--- 摘抄自:https://www.liaoxuefeng.com/wiki/0014316089557264a6b348958f449949df42a6d3a2e542c000 ...

  7. 优美的代码:do...while(0)

    1.背景 最近再看一个开源代码的时候,看到很多宏经常这么写的: #define XXX do{\ ...\ }) 一眼看到的时候就知道这一份代码执行一次,那么do...while还有什么意义呢?在查阅 ...

  8. hadoop之安全篇

    ---------------持续更新中------------------- hadoop集群安全架构 如下图所示: --------------------------未完待续---------- ...

  9. .NET面试题系列(一)基本概念

    什么是CLR CLR常用简写词语,CLR是公共语言运行库(Common Language Runtime)和Java虚拟机一样也是一个运行时环境,它负责资源管理(内存分配和垃圾收集等),并保证应用和底 ...

  10. redis基础之redis-sentinel(哨兵集群)(六)

    前言 redis简单的主从复制在生产的环境下可能是不行的,因为从服务器只能读不能写,如果主服务器挂掉,那么整个缓存系统不能写入了:redis自带了sentinel(哨兵)机制可以实现高可用. redi ...