08 数据库优化方案(一):查询请求增加时,如何做主从分离?

上一个内容介绍了池化技术,现在的架构图如下所示:


image.png

此时数据库还是单机部署,根据一些云厂商的Benchmark的结果,在4核8G的机器上运行MySQL5.7时,大概可以支撑500的TPS和10000的QPS。这时,如果负责人说要进行全渠道推广,这无疑会引发查询量骤增的问题。那么当查询请求增加时,应该如何做主从分离来解决问题。

主从读写分离
大部分系统的访问模型是读多写紹,读写请求量的差距可能达到几个数量级。因此我们优先考虑数据库如何扛住更高的查询请求,那么首先需要把读写流量分开,这样才方便针对流量做单独的扩展,这就是主从读写分离。

这其实是个流量分离的问题,这个方法本身是一种常规的做法,即使在一个大的项目中,它也是一个应对数据库突发读流量的有效方法。

曾经出现过前端流量突增导致从库负载过高的问题,DBA会优先做一个从库扩容上去,这样对数据库的读流量会落入多个从库上,从库的负载就降了下来,然后研发再考虑使用什么方案将流量挡在数据库层之上。

主从读写的两个技术关键点
一般来说主从读写分离机制中,我们将一个数据库的数据拷贝为一份或者多份,并且写入到其他的数据库服务器中,原始的数据库我们称之为主库,主要负责数据库的写入,拷贝的目标数据库我们称为从库,主要负责支持数据查询。可以看到,主从读写分离有两个技术上的关键点:

  • 一个是数据的拷贝,我们称为主从复制;
  • 在主从分离的情况下,我们如何屏蔽主从分离带来的访问数据库方式的变化,让开发像是在使用单一数据库一样。

1.主从复制
我们先以MySQL为例介绍一下主从复制。
MySQL的主从复制是依赖于binlog的,也就是记录MySQL上的所有变化并以二进制形式保存在磁盘上二进制日志文件。主从复制就是将binlog中的数据从主库传输到从库上,一般这个过程是异步的,即主库上的操作不会等待binlog同步的完成。
主从复制的过程是这样的:首先从库在连接到主节点时会创建一个IO线程,用以请求主库更新的binlog,并且把接收到的binlog信息写入一个叫做relay log的日志文件中,而主库也会创建一个log dump线程来发送binlog给从库;同时从库还会创建一个SQL线程读取relay log中的内容,并且在从库中做回访,最终实现主从的一致性。这是一种比较常见的主从复制方式。

在这个方案中,使用独立的log dump线程是一种异步的方式,可以避免对主库的主题更新流程产生影响,而从库在接收到信息后并不是写入从库的存储中,而是写入一个relay log,是避免从库实际存储会比较耗时,最终造成从库和主库的延迟变长。


image

会发现基于性能的考虑,主库的写入流程并没有等待主从同步完成就会返回结果,那么在极端的情况下,比如说主库上binlog还没有来得及刷新到磁盘上就出现了磁盘损坏或者机器掉电,这就会导致binlog的丢失,最终造成主从数据的不一直。不过这种情况出现的概率很低,对于互联网的项目来说是可以容忍的。

做了主从复制后,我们就可以在写入时只写主库,在读数据时只读从库,这样即使写请求会锁表或者锁记录,也不会影响到读请求的执行。同时在读流量比较大的情况下,我们可以部署多个从库共同承担读流量,这就是说说的“一主多从”部署方式,在垂直电商项目中就可以通过这种方式来抵御较高的并发读流量,另外,从库可以当成一个备库来使用,以避免主库故障导致数据丢失。

那么是不是我无限的增加从库的数量就可以抵抗大量的并发呢?实际上并不是,因为随着从库数量的增加,从库连接上来的IO线程比较多,主库也需要创建同样多的log dump线程来处理复制的请求,对于主库资源消耗比较高,同时受限于主库的网络带宽,所以在实际使用中,一般一个主库最多挂3~5个从库。

当然主从复制也有一些缺陷,除了带来部署上的复杂度,还有就是会带来一定的主从同步的延迟,这种延迟有时候会对业务产生一定的影响。比如:
在发微博的过程中会有些同步的操作,像是更新数据库的操作,也有一些异步的操作,比如说将微博的信息同步给审核系统,所以我们在更新完主库之后,会将微博的ID写入消息队列,再由队列处理机依据ID在从库中获取微博信息再发送给审核系统。此时如果主从数据库存在延迟,会导致在从库纵获取不到微博信息,整个流程会出现异常。

image.png

这种问题解决的思路有很多,核心思想就是尽量不去从库中查询信息,以上面的例子来说,有三种解决方案:
第一种方案是数据的冗余。你可以在发送队列时不仅仅发送微博ID,而是发送队列需要的所有微博信息,借此避免从数据库中重新查询数据。
第二种方案是使用缓存。我们可以在同步写数据的同时,也把微博的数据写入到Memcached缓存里面,这样队列处理机在获取微博信息的时候会优先查询缓存,这样也可以保证数据的一致性。
最后一种方案是查询主库。我们可以在队列处理机中不查询从库而改为查询主库。不过这种方式使用起来要慎重,要明确查询的量级不会很大,是在主库的可承受范围之内,否则会对主库造成比较大的压力。

优先考虑第一种方案,因为足够简单,不过可能造成单条消息比较大,从而增加了消息发送的带宽和时间。

缓存的方式比较适合新增数据的场景,在更新数据的场景下,先更新缓存可能会造成数据的不一致。

最后不建议使用第三种方案,因为这个方案要提供一个查询主库的接口,在团队开发的过程中,很难保证其他成员不会滥用这个方法,而一旦主库承担了大量的读请求导致崩溃,对于整体系统的影响是巨大的。

主从同步的延迟,使我们排查问题时很容易忽略的一个问题。有时候我们遇到从数据库中获取不到信息的诡异问题时,会纠结于代码中是否有一些逻辑会把之前写入的内容删除,但是优惠发下你,过了一段时间再去查询又可以读到数据了,这几本就是主从延迟在作怪,所以,我们一般会把从库落后的时间作为一个重点的数据库指标做监控和报警,正常的时间是在毫秒级别,一旦落后的时间达到了秒级别就需要告警了。

2.如何访问数据库
我们已经使用主从复制技术将数据复制到了多个节点,也实现了数据库的读写分离。这时,对于数据库的使用方式发生了变化。以前只需要使用一个数据库地址就好了,现在需要使用光一个主库地址和多个从库地址,并且需要区分写入操作和查询操作,如果结合“分库分表”,复杂度会提升更多。为了降低实现的复杂度,业界涌现了很多数据库中间件来解决数据库的访问问题,这些中间件可以分为两类

第一类以淘宝的TDDL(Taobao Distributed Data Layer)为代表,以代码形式内嵌运行在应用程序内部,可以把它看成是一种数据源的代理,它的配置管理着多个数据源,每个数据源对应一个数据库,可能是主库,可能是从库。当有一个数据库请求时,中间件将SQL语句发给某一个指定的数据源来处理,然后将处理结果返回。

这一类中间件的优点是简单易用,没有多余的部署成本,因为它是植入到应用程序内部,与应用成语一同运行的,所以比较适合运维能力较弱的小团队使用;缺点是缺乏多语言的支持,目前业界这一类的主流方案除了TDDL,还有早期的网易DDB,它们都是Java开发的,无法支持其他语言,另外版本升级也依赖使用方更新,比较困难。

另一类是单独部署的代理层方案,这一类方案代表比较多,如早起的阿里巴巴开源的Cobar。

这一类中间件部署在独立的服务器上,业务代码如同在使用单一数据库一样使用它,实际上它内部管理着很多的数据源,当有数据库请求时,它会对SQL语句做必要的改写,然后发往指定的数据源。

它一般使用标准的MySQL通信协议,所以可以很好的支持多语言。由于它是独立部署的,所以也比较方便进行维护升级,比较适合有一定运维能力的大中型团队使用。它的缺陷是所有的sql语句都需要跨两次网络:从应用到代理层和从代理层到数据源,所以性能上会有一些损耗。


image.png

在使用中间件的时候一定要保证对于中间件有足够深入的了解,否则一旦出现问你就无法快速的解决。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,294评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,493评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,790评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,595评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,718评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,906评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,053评论 3 410
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,797评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,250评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,570评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,711评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,388评论 4 332
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,018评论 3 316
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,796评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,023评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,461评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,595评论 2 350

推荐阅读更多精彩内容