从0开始学架构
李运华
资深技术专家
立即订阅
38975 人已学习
课程目录
已完结 59 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 照着做,你也能成为架构师!
免费
基础架构 (13讲)
01 | 架构到底是指什么?
02 | 架构设计的历史背景
03 | 架构设计的目的
04 | 复杂度来源:高性能
05 | 复杂度来源:高可用
06 | 复杂度来源:可扩展性
07 | 复杂度来源:低成本、安全、规模
08 | 架构设计三原则
09 | 架构设计原则案例
10 | 架构设计流程:识别复杂度
11 | 架构设计流程:设计备选方案
12 | 架构设计流程:评估和选择备选方案
13 | 架构设计流程:详细方案设计
高性能架构模式 (8讲)
14 | 高性能数据库集群:读写分离
15 | 高性能数据库集群:分库分表
16 | 高性能NoSQL
17 | 高性能缓存架构
18 | 单服务器高性能模式:PPC与TPC
19 | 单服务器高性能模式:Reactor与Proactor
20 | 高性能负载均衡:分类及架构
21 | 高性能负载均衡:算法
高可用架构模式 (10讲)
22 | 想成为架构师,你必须知道CAP理论
23 | 想成为架构师,你必须掌握的CAP细节
24 | FMEA方法,排除架构可用性隐患的利器
25 | 高可用存储架构:双机架构
26 | 高可用存储架构:集群和分区
27 | 如何设计计算高可用架构?
28 | 业务高可用的保障:异地多活架构
29 | 异地多活设计4大技巧
30 | 异地多活设计4步走
31 | 如何应对接口级的故障?
可扩展架构模式 (6讲)
32 | 可扩展架构的基本思想和模式
33 | 传统的可扩展架构模式:分层架构和SOA
34 | 深入理解微服务架构:银弹 or 焦油坑?
35 | 微服务架构最佳实践 - 方法篇
36 | 微服务架构最佳实践 - 基础设施篇
37 | 微内核架构详解
架构实战 (13讲)
38 | 架构师应该如何判断技术演进的方向?
39 | 互联网技术演进的模式
40 | 互联网架构模板:“存储层”技术
41 | 互联网架构模板:“开发层”和“服务层”技术
42 | 互联网架构模板:“网络层”技术
43 | 互联网架构模板:“用户层”和“业务层”技术
44 | 互联网架构模板:“平台”技术
45 | 架构重构内功心法第一式:有的放矢
46 | 架构重构内功心法第二式:合纵连横
47 | 架构重构内功心法第三式:运筹帷幄
48 | 再谈开源项目:如何选择、使用以及二次开发?
49 | 谈谈App架构的演进
50 | 架构实战:架构设计文档模板
特别放送 (7讲)
架构专栏特别放送 | “华仔,放学别走!”第1期
架构专栏特别放送 | “华仔,放学别走!” 第2期
如何高效地学习开源项目 | “华仔,放学别走!” 第3期
架构师成长之路 | “华仔,放学别走!” 第4期
架构师必读书单 | “华仔,放学别走!” 第5期
新书首发 | 《从零开始学架构》
致「从0开始学架构」专栏订阅用户
结束语 (1讲)
结束语 | 坚持,成就你的技术梦想
从0开始学架构
登录|注册

14 | 高性能数据库集群:读写分离

李运华 2018-05-29
“从 0 开始学架构”专栏已经更新了 13 期,从各个方面阐述了架构设计相关的理论和流程,包括架构设计起源、架构设计的目的、常见架构复杂度分析、架构设计原则、架构设计流程等,掌握这些知识是做好架构设计的基础。
在具体的实践过程中,为了更快、更好地设计出优秀的架构,除了掌握这些基础知识外,还需要掌握业界已经成熟的各种架构模式。大部分情况下,我们做架构设计主要都是基于已有的成熟模式,结合业务和团队的具体情况,进行一定的优化或者调整;即使少部分情况我们需要进行较大的创新,前提也是需要对已有的各种架构模式和技术非常熟悉。
接下来,我将逐一介绍最常见的“高性能架构模式”“高可用架构模式”“可扩展架构模式”,这些模式可能你之前大概了解过,但其实每个方案里面都有很多细节,只有深入的理解这些细节才能理解常见的架构模式,进而设计出优秀的架构。
虽然近十年来各种存储技术飞速发展,但关系数据库由于其 ACID 的特性和功能强大的 SQL 查询,目前还是各种业务系统中关键和核心的存储系统,很多场景下高性能的设计最核心的部分就是关系数据库的设计。
不管是为了满足业务发展的需要,还是为了提升自己的竞争力,关系数据库厂商(Oracle、DB2、MySQL 等)在优化和提升单个数据库服务器的性能方面也做了非常多的技术优化和改进。但业务发展速度和数据增长速度,远远超出数据库厂商的优化速度,尤其是互联网业务兴起之后,海量用户加上海量数据的特点,单个数据库服务器已经难以满足业务需要,必须考虑数据库集群的方式来提升性能。
从今天开始,我会分几期来介绍高性能数据库集群。高性能数据库集群的第一种方式是“读写分离”,其本质是将访问压力分散到集群中的多个节点,但是没有分散存储压力;第二种方式是“分库分表”,既可以分散访问压力,又可以分散存储压力。先来看看“读写分离”,下一期我再介绍“分库分表”。

读写分离原理

读写分离的基本原理是将数据库读写操作分散到不同的节点上,下面是其基本架构图。
读写分离的基本实现是:
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学架构》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(87)

  • 海。
    老师,您好
    我个人的想法是可以加入缓存,例如注册后登录这种业务,可以在注册后加入数据库,并加入缓存,登录的时候先查缓存再查库表。
    例如存入redis中并设置十分钟的过期时间。登录的时候先查redis,再查库表,如果redis中没有,说明就是过期的数据,这时候查从机就肯定存在了,希望能得到老师的点评,谢谢。

    作者回复: 赞同,并不是说一有性能问题就上读写分离,而是应该先优化,例如优化慢查询,调整不合理的业务逻辑,引入缓存等,只有确定系统没有优化空间后,才考虑读写分离或者集群

    2018-05-30
    85
  • tangfengr
    我认为读写分离适用单机并发无法支撑并且读的请求更多的情形。在单机数据库情况下,表上加索引一般对查询有优化作用却影响写入速度,读写分离后可以单独对读库进行优化,写库上减少索引,对读写的能力都有提升,且读的提升更多一些。
    不适用的情况:1如果并发写入特别高,单机写入无法支撑,就不适合这种模式。
    2 通过缓存技术或者程序优化能够满足要求

    作者回复: 赞同👍

    2018-07-19
    41
  • 性能
    我们做网银系统,用redis存了一些不太重要的数据,比如数据字典信息,作为缓存。但是不太敢把用户权限,交易数据等重要信息存在缓存里,因为redis并不保证事务,我们担心一旦缓存服务器宕机或者失败会影响银行业务。所以缓存的作用也不是很大,还是把大部分读数据的压力放到了数据库上,您说我们这种担心有必要吗?如果单库后续扛不住压力,是否读写分离比加缓存更好一些?

    作者回复: 交易型业务缓存应用不多,缓存一般总在查询类业务上,你们的担心有一定必要

    2018-06-03
    18
  • narry
    个人感觉,读写分离适合读压力比写压力大很多的业务类型,最终的瓶颈应该是出现在承担写操作的主机上,最大规模和这台主机的iops等能力相关
    2018-05-29
    16
  • 侯海佳
    我认为读写分离适合类似微博这种业务:读多写少
    2018-05-29
    11
  • LONGER
    目前还在用单机一直在扛着,目前数据量在百万万,在不停的优化,建立冗余等方式,还在保持着一个较快的查询速度,因为业务查询的关系,多表之间的关联,聚合,很难避免,一直想引用缓存,但是查询的条件太多,很动态,就不知道如何设计缓存,类似于京东筛选物品,多品类,多维度筛选,不知道大牛有何高见

    作者回复: 按照2-8原则,选出占访问量80%的前20%的请求条件缓存,因为大部分人的查询不会每次都非常多条件,以手机为例,查询苹果加华为的可能占很大一部分

    2018-06-05
    9
  • 合民
    读写分离,主从架构,顾名思义,写不变,主要解决高性能读的问题,所以适用场景自然是读多写少的情况。比如类似于博客、中小型朋友圈,这种一般写数据库后基本不变,但是很多人会去访问,频繁的读。我认为如果缓存能支撑的话就没必要上读写分离,相对来说缓存更简单。
    2018-05-31
    8
  • rubin
    读写分离的前提是并发量大,单机已经不能处理该数量的并发请求了,想要解决问题就得做作拆分,于是有了读写分离,主库负责写,从库负责读,降低了同台机器并发请求,当读越来越多时,可扩充从库,写越来越多时,只好拆分业务或分库分表,如:注册功能,单独出来做一个注册的微服务,但还是会到达一个瓶颈,没做过,不知道能支持多少的并发?

    作者回复: 要具体测试,不同业务复杂度不同

    2018-05-30
    8
  • 彡工鸟
    是否还应该加上一个,当单机写顶不住压力后,就可以做数据库拆分了,例如业务纵向拆分,连同数据库一起,就变成分布式服务,微服务了:)

    作者回复: 说法没错,但具体实施的时候要注意,不要一有压力就上读者分离,因为很多时候其实是sql语句或者业务逻辑有问题,因此先优化,只有优化后也无法满足要求的时候才考虑读者分离或者集群

    2018-05-30
    7
  • 刘岚乔月
    请问 对于主从出现的数据同步延时问题 在实际生产落地 真的只有把重要的查询指向主吗 还有其他真正的落地方案吗

    作者回复: 当然是真的呀,难道我还会骗你不成?😂
    如果不想用这种方式,用缓存是可以规避这个问题的,但其实这时候的方案就不是读写分离了

    2018-05-29
    7
  • 云学
    相比于前面的几篇高大上文章,这篇更接地气
    2018-05-29
    7
  • lee
    SQL优化——缓存——读写分离——分库分表
    2019-01-23
    6
  • 小喵喵
    公司现在的系统时采用读写分离的,是中间层程序封装的api,第一套分两类:1读主库,2.读从库.然后客户端程序通过传递SQL或存储过程和参数的值调用。
    第二套只提供一个api,通过传递一个布尔值来判断是走主库还是从库,这套是供自动调度工具来调用。这两套api都有一个共同点,就程序猿必须手动指定是走主库还是从库。现在出现的问题是大量的SQL应该走从库,结果很多菜鸟都走了主库,导致现在的主库压力很大。听了你的课程后觉得走主库还是从库不应该由程序猿自己指定,而是由中间层来判断。具体如何做呢,请老师指点一下。客户端有时传递一些复杂的SQL,比如,先做更新然后再查。

    作者回复: 默认读走从库,写走主库,特殊情况才由程序员制定,可以代码指定,可以配置指定,这样就不会出现大量sql都走主库了

    2018-06-03
    6
  • @漆~心endless
    并非所有系统都需要进行读写分离,正如之前讲得架构三原则,其中根据“合适原则”的规定,先确认系统的业务量是否出现了数据库的性能问题。如果是,首先通过优化MySQL语句等,如果还是达不到要求的性能指标,则需进行读写分离。毕竟读写分离会引入一系列不可预知的问题,如数据不同步。
    2018-05-31
    6
  • null
    re: 写操作后的读操作指定发给数据库主服务器

    后端无法知道本次请求是否为写操作之后的读,因此会依赖前端传递一个参数,如 target_db=master / slave,来决定目标数据库。
    所以这种方式,需要在前后端代码实现相关逻辑,代码耦合较大。

    这种解决方案是否只提供了一种思路,实际开发时很少使用这方案,不知道理解是否正确,谢谢!

    作者回复: 是的,对代码逻辑有要求,

    2018-05-29
    6
  • allen.huang
    老师您好,
    像我们数据库服务器只有一台,并且现在业务量也越来越大,尤其是中午,晚上加起来大概是5,6个小时是业务高峰,订餐的量还挺大。前台读写操作都很频繁,
    后来就是要看数据统计啊之类的,客户也是经常在使用。在业务高峰期,他们还要进去看实时交易情况。这样子经常会出现磁盘IO报警。
    我也在尝试规划做读写分离,但是像业务前台做了以后,就会出现数据延时的情况,这样子业务处理就有问题。
    我现在初步规划是前台都用主,后台读写分离,这样子是否合理,有经验的同学也给予我指导谢谢😜

    作者回复: 面向用户的业务读写都用主,面向客户和运营的业务可以读写分离,大部分场景没必要看实时交易情况的

    2018-08-14
    4
  • 老邪
    你好,华仔,请问文章内的架构图用的什么软件,谢谢!

    作者回复: Libre office的Draw

    2018-07-19
    4
  • 刘志刚
    读写分离比较适用于类似消息记录,对于写和读业务的强实时性要求不到苛刻的地步的情况,而且做的时候这种跟业务量还是有比较大关系的,比如,业务量的订单量每年都不超过1千万,整天去做分库分表倒不如好好优化下sql写法,如果订单量每天都超过好几百万,那这个必要性就很强了!

    作者回复: 赞,先优化

    2018-05-29
    4
  • 马广乐
    加个缓存能解决写完立即读的场景吗,老师。

    作者回复: 可以的,但那是另外一个方案了,很多场景就算用了缓存也要读写分离

    2018-05-29
    4
  • 姜泮昌
    读写分离适用于单服务器无法满足所有请求的场景,从请求类型的角度对服务器进行拆分,但这样在要求硬件资源能够支撑的同时,对代码实现也有更高的要求。

    作者回复: 天下没有免费的午餐😃

    2018-05-29
    4
收起评论
87
返回
顶部