高并发系统设计40问
唐扬
美图公司技术专家
立即订阅
9202 人已学习
课程目录
已更新 38 讲 / 共 40 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 为什么你要学习高并发系统设计?
免费
基础篇 (6讲)
01 | 高并发系统:它的通用设计方法是什么?
02 | 架构分层:我们为什么一定要这么做?
免费
03 | 系统设计目标(一):如何提升系统性能?
04 | 系统设计目标(二):系统怎样做到高可用?
05 | 系统设计目标(三):如何让系统易于扩展?
06 | 面试现场第一期:当问到组件实现原理时,面试官是在刁难你吗?
演进篇 · 数据库篇 (5讲)
07 | 池化技术:如何减少频繁创建数据库连接的性能损耗?
08 | 数据库优化方案(一):查询请求增加时,如何做主从分离?
09 | 数据库优化方案(二):写入数据量增加时,如何实现分库分表?
10 | 发号器:如何保证分库分表后ID的全局唯一性?
11 | NoSQL:在高并发场景下,数据库和NoSQL如何做到互补?
演进篇 · 缓存篇 (6讲)
12 | 缓存:数据库成为瓶颈后,动态数据的查询要如何加速?
13 | 缓存的使用姿势(一):如何选择缓存的读写策略?
14 | 缓存的使用姿势(二):缓存如何做到高可用?
15 | 缓存的使用姿势(三):缓存穿透了怎么办?
16 | CDN:静态资源如何加速?
加餐 | 数据的迁移应该如何做?
演进篇 · 消息队列篇 (6讲)
17 | 消息队列:秒杀时如何处理每秒上万次的下单请求?
18 | 消息投递:如何保证消息仅仅被消费一次?
19 | 消息队列:如何降低消息队列系统中消息的延迟?
20 | 面试现场第二期:当问到项目经历时,面试官究竟想要了解什么?
用户故事 | 从“心”出发,我还有无数个可能
期中测试 | 10道高并发系统设计题目自测
演进篇 · 分布式服务篇 (9讲)
21 | 系统架构:每秒1万次请求的系统要做服务化拆分吗?
22 | 微服务架构:微服务化后,系统架构要如何改造?
23 | RPC框架:10万QPS下如何实现毫秒级的服务调用?
24 | 注册中心:分布式系统如何寻址?
25 | 分布式Trace:横跨几十个分布式组件的慢请求要如何排查?
26 | 负载均衡:怎样提升系统的横向扩展能力?
27 | API网关:系统的门面要如何做呢?
28 | 多机房部署:跨地域的分布式系统如何做?
29 | Service Mesh:如何屏蔽服务化系统的服务治理细节?
演进篇 · 维护篇 (5讲)
30 | 给系统加上眼睛:服务端监控要怎么做?
31 | 应用性能管理:用户的使用体验应该如何监控?
32 | 压力测试:怎样设计全链路压力测试平台?
33 | 配置管理:成千上万的配置项要如何管理?
34 | 降级熔断:如何屏蔽非核心系统故障的影响?
高并发系统设计40问
登录|注册

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

唐扬 2019-10-04
你好,我是唐扬。
上节课,我们用池化技术解决了数据库连接复用的问题,这时,你的垂直电商系统虽然整体架构上没有变化,但是和数据库交互的过程有了变化,在你的 Web 工程和数据库之间增加了数据库连接池,减少了频繁创建连接的成本,从上节课的测试来看性能上可以提升 80%。现在的架构图如下所示:
此时,你的数据库还是单机部署,依据一些云厂商的 Benchmark 的结果,在 4 核 8G 的机器上运 MySQL 5.7 时,大概可以支撑 500 的 TPS 和 10000 的 QPS。这时,运营负责人说正在准备双十一活动,并且公司层面会继续投入资金在全渠道进行推广,这无疑会引发查询量骤然增加的问题。那么今天,我们就一起来看看当查询请求增加时,应该如何做主从分离来解决问题。

主从读写分离

其实,大部分系统的访问模型是读多写少,读写请求量的差距可能达到几个数量级。
这很好理解,刷朋友圈的请求量肯定比发朋友圈的量大,淘宝上一个商品的浏览量也肯定远大于它的下单量。因此,我们优先考虑数据库如何抗住更高的查询请求,那么首先你需要把读写流量区分开,因为这样才方便针对读流量做单独的扩展,这就是我们所说的主从读写分离。
它其实是个流量分离的问题,就好比道路交通管制一样,一个四车道的大马路划出三个车道给领导外宾通过,另外一个车道给我们使用,优先保证领导先行,就是这个道理。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《高并发系统设计40问》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(38)

  • 老男孩 置顶
    我觉得进入演进篇以后干货越来越多了。关于理论基础大家都能泛泛的谈一谈,可具体落地实操,老师的经验和能力就体现出来了。关于读写分离,主从同步延时出现的诡异现象,我之前也遇到过。我之前项目最开始没有只是配置了2个数据源,由开发人员选择写主库,读存库。后来发现很多读操作也放到主库上了,理由就是在一些场景下会出现诡异的数据不一致。于是,使用了mycat做代理,开发是比以前方便了,但诡异问题依然存在,又换成了atlas,还是不行。就如同老师说的一样,在没有完全深入了解组件的情况下贸然使用,本来是玩组件,结果被组件玩了。没办法,只好把查询放到一个事务里边,这样代理就会去主库中执行,但这样无异于还是增加的主库的压力。老师在专栏中提供基于消息队列和缓存的方案给我很好的启发,期待后续更多干货。
    2019-10-09
    1
    12
  • helloworld
    给主从复制增加延迟告警的思路很好,另外,老师能具体讲解下QPS和TPS的区别?网上查询了很多资料没有权威的解释。感谢!打卡08

    作者回复: 我理解的QPS是每秒查询数,是针对读请求的
    TPS是每秒执行事务数,倾向于写请求

    2019-10-08
    3
    5
  • mrtasesrch
    总结
    1 主从原理:主库通过同步binlog到从库,relaylog去读
    2 从库有延迟可以通过缓存 冗余数据来解决
    3 4核8g TPS 500 QPS 10000

    作者回复: 👍

    2019-10-06
    5
  • 每天晒白牙
    Kafka的数据会保存到leader副本的log文件中并写入磁盘,随后follower副本会对数据进行同步
    2019-10-04
    3
    5
  • longslee
    “在 4 核 8G 的机器上运 MySQL 5.7 时,大概可支撑 500 的 TPS 和 10000 的 QPS”,老师,可以介绍下,挂了几个读库后(比如3个),同样的机器配置,QPS能上升到多少?

    作者回复: 理论上是三倍,取决于从库的负载均衡是否均匀,另外这个是benchmark结果,只是给大家一个感性认识,实际项目要比这个量极小

    2019-10-10
    1
    3
  • xu晓晨
    平常使用的redis也是用复制的方式 来保持数据同步。redis是以2.8版本为分界。2.8版本之前用用的是性能较差的复制和命令传播。首先是从服务器发生同步操作sync,主服务器会执行bgsave生成一个全量文件的rdb文件 然后传输给从服务器。同时主服务器会把这一过程中执行的写入命令写入缓存区。从服务器会把rdb文件进行一次全量加载。加载完毕后 主服务器会把缓存区中的写入命令传给从服务器。从服务器执行命令后 两个服务器的数据就一致了。
    这种方式每次如果网络出现故障 故障重连后都要进行全量数据的复制。对主服务器的压力太大 也会增加主从网络传输的资源消耗。
    redis2.8版本之后优化了这一部分缺陷 增加了部分重同步功能。部分同步就是同步故障后的一部分数据 而不是全量数据。这种优化在量级非常大的情况下 提生的效率是相当客观的。
    2019-10-08
    3
  • 无形
    之前发生过的一个问题,用Redis主从同步,写入Redis的数据量太大,没加频次控制,导致每秒几十万写入,主从延迟过大,运维频频报警,在主库不挂掉的情况下,这样大量写入会不会造成数据丢失?

    作者回复: 之前遇到过 如果主从延迟很大,数据会堆积到redis主库的发送缓冲区,会导致主库oom

    2019-11-01
    1
    2
  • Hwan
    老师,为啥优先读写分离,然后再缓存呢,是从那方面考虑的呢

    作者回复: 从开发和维护的难度考虑。引入缓存会引入复杂度,你要考虑缓存数据一致性,穿透,防雪崩等问题,并且也多维护一类组件

    2019-10-29
    1
    2
  • 何蓝逗
    主库宕机之后,binlog丢失导致的主从数据不一致是不是只能手动恢复?

    作者回复: 在我来看是的

    2019-10-10
    2
  • 哇哦
    主从分离的,如果主节点写入sql,后面同步到从节点,那个时候,从节点实际上即在执行写,也在支持读。那主从分离的作用是保证主节点正常写?其他从节点只是通过增加机器来分担读数据io吗

    作者回复: 是的

    2019-10-04
    1
    2
  • xu晓晨
    个人感觉中间件不是什么地方都需要高可用 得看具体的业务场景。大多的缓存场景 并发不是很高的话 可以容忍暂时穿透查库。但是一些涉及到业务逻辑的地方 就必须高可用了

    作者回复: 可用性是是否容忍故障,如果穿透不会引发故障,是可以的

    2019-10-10
    1
  • 趙衍
    请问一下来时,通过缓存来抗住高并发的读请求和通过MySQL的读写分离来抗高并发他们之间的区别在哪里呢?分别有哪些适用的场景?

    作者回复: 优先用读写分离,扛不住了再考虑缓存

    2019-10-09
    3
    1
  • Julien
    2. 主从的延迟问题,很多诡异的读取不到数据的问题都可能会和它有关,如果你遇到这类问题不妨先看看主从延迟的数据。

    请问一下,如果出现了延迟较大导致从库读不到数据,怎样在代码层面一劳永逸地解决呢?谢谢老师~

    作者回复: 文章中有提到的,三种方案
    1. 把数据都传过来,不查数据库
    2. 中缓存,从缓存读
    3. 直接读主库

    2019-10-09
    3
    1
  • 三年过后
    老师讲得很好!案例说到主从的延迟时间预警,未能详细到如何通过哪个数据库中的哪个指标来判别?经验中,我记得是,在从从库中,通过监控show slave status\G命令输出的Seconds_Behind_Master参数的值来判断,是否有发生主从延时。这个参数值是通过比较sql_thread执行的event的timestamp和io_thread复制好的 event的timestamp(简写为ts)进行比较,而得到的这么一个差值。 但是,问题来了,如果复制同步主库bin_log日志的io_thread线程负载过高的话,那么,Seconds_Behind_Master这个值就一直处于0。也是无法预警的,确切地说,通过Seconds_Behind_Master这个值来判断延迟是不够准确的。 不知,还有其他更好的方式?

    作者回复: 印象中可以通过比对master和slave的bin log位置

    2019-10-04
    1
  • 朋朋
    写入到 HDFS 中文件也会被复制到多个 DataNode 中。只是不同的组件对于复制的一致性、延迟要求不同,采用的方案也不同。 这句话 是HDFS中间件 还是中文件? 我有点读不通顺

    作者回复: 写入到HDFS中,文件也会被复制到多个DataNode中

    2019-12-02
  • 退役的球童
    老师,你好。有关演进篇的内容能不能附带提供一下代码化的实验demo啊。这样子对于学习帮助更大。

    作者回复: 会有的~ 感谢建议~

    2019-12-01
  • 被过去推开
    老师你好,我以前想要给公司分库分表,后来觉得有几个问题放在我面前,就搁浅了,现在只是挂了一个从库。
    最主要的问题:我们公司每天产生许多业务订单,如果以用户id进行hash计算,分发到不同的库,对前台用户订单查询有利,但后台系统页面需要查看全部订单,以倒序排列,这样子的sql会不会执行很慢,毕竟是订单分散到几个库了。老师有好的分库分表方案吗?

    作者回复: 后台系统不能直接查询分库分表的数据,可以把数据同步到单独的一个后台库中,或者同步到es里面

    2019-11-27
    2
  • SuperYue
    主从延迟问题的另一个方案,可以先读从库,根据实际业务,如果查询为null或者可以判断出不是最新数据,再走一次主库
    让从库档住大量查询,主库来补漏高延迟数据

    作者回复: 其实你很难判断是不是“最新”数据

    2019-11-26
  • 布小丫学编程
    Canal监听binlog是不是解决延迟的另一种方案呢?
    2019-11-19
  • 雷霹雳的爸爸
    针对老师的一课一思...我认得得东东已经被老师说的七七八八了,能很快想到的,也就是kafka了,具体原理我还真没能力说清楚,说明个人升级之路和老师普及事业都是任重而道远啊,附上复制原理一篇 https://engineering.linkedin.com/kafka/intra-cluster-replication-apache-kafka 供同好参阅,成文比较早,不知道细节上和目前的版本有什么差异,所以立个免责得flag吧

    其他的问题,主要是延伸阅读,考虑到主题(其实说的是分散数据库得读请求,但是难以避免的得围绕着复制来)和篇幅(太长估计没人看,现在看评论区都有看不仔细或不看完了就发问甚至敢直接质疑得),完整得讲解MySQL复制,例如涵盖半同步和GTID基于事务得复制等等,以及这些不同方案在一致性上得细节差异,可能不太容易做得到,所以考虑到面向互联网的场景做一些课程内容裁剪也是很有必要的;只是,考虑到可能很多专栏读者,比如我,可能并非真一定是面向消费类用户的互联网场景,即便是面向海量消费类用户的互联网应用场景,也需要在一致性、可用性等方面作必要的权衡,所以适当的扩展阅读参考指引感觉也是有必要的
    2019-11-06
收起评论
38
返回
顶部