从 0 开始学架构
李运华
网名“华仔”,前阿里资深技术专家(P9)
149501 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 66 讲
结束语 (1讲)
结课测试 (1讲)
从 0 开始学架构
15
15
1.0x
00:00/00:00
登录|注册

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

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

读写分离原理

读写分离的基本原理是将数据库读写操作分散到不同的节点上,下面是其基本架构图。
读写分离的基本实现是:
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《从 0 开始学架构》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(127)

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

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

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

    作者回复: 赞同👍

    7
    123
  • LONGER
    目前还在用单机一直在扛着,目前数据量在百万万,在不停的优化,建立冗余等方式,还在保持着一个较快的查询速度,因为业务查询的关系,多表之间的关联,聚合,很难避免,一直想引用缓存,但是查询的条件太多,很动态,就不知道如何设计缓存,类似于京东筛选物品,多品类,多维度筛选,不知道大牛有何高见

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

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

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

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

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

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

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

    3
    19
  • spoofer
    前段时间,老大在大表上执行了delete操作,然后主从就不同步了。然后线上各种bug,最后我花了5分钟排查到了问题(运维团队比较小,我打杂的)。解决方式,线上业务部分限流,关键业务读写紧急切换到主库,修复主从不同步问题,切换回读写分离配置。最后发现是老大做了骚操作,一问才知道,是个日志表,清理一下。😂我。。。

    作者回复: 我们要求线上delete每次不能超过1000条,超过就定时循环操作

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

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

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

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

    2
    13
  • rubin
    读写分离的前提是并发量大,单机已经不能处理该数量的并发请求了,想要解决问题就得做作拆分,于是有了读写分离,主库负责写,从库负责读,降低了同台机器并发请求,当读越来越多时,可扩充从库,写越来越多时,只好拆分业务或分库分表,如:注册功能,单独出来做一个注册的微服务,但还是会到达一个瓶颈,没做过,不知道能支持多少的并发?

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

    12
收起评论
显示
设置
留言
99+
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部