后端存储实战课
李玥
京东零售计算存储平台部资深架构师
立即订阅
4535 人已学习
课程目录
已完结 28 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (2讲)
开篇词 | 从今天起,换种方式学存储
免费
课前加餐 | 电商系统是如何设计的?
创业篇 (7讲)
01 | 创建和更新订单时,如何保证数据准确无误?
02 | 流量大、数据多的商品详情页系统该如何设计?
03 | 复杂而又重要的购物车系统,应该如何设计?
04 | 事务:账户余额总是对不上账,怎么办?
05 | 分布式事务:如何保证多个系统间的数据是一致的?
06 | 如何用Elasticsearch构建商品搜索系统?
07|MySQL HA:如何将“删库跑路”的损失降到最低?
高速增长篇 (7讲)
08 | 一个几乎每个系统必踩的坑儿:访问数据库超时
09 | 怎么能避免写出慢SQL?
10 | 走进黑盒:SQL是如何在数据库中执行的?
11 | MySQL如何应对高并发(一):使用缓存保护MySQL
12 | MySQL如何应对高并发(二):读写分离
13 | MySQL主从数据库同步是如何实现的?
14 | 订单数据越来越多,数据库越来越慢该怎么办?
海量数据篇 (10讲)
15 | MySQL存储海量数据的最后一招:分库分表
16 | 用Redis构建缓存集群的最佳实践有哪些?
17 | 大厂都是怎么做MySQL to Redis同步的?
18 | 分布式存储:你知道对象存储是如何保存图片文件的吗?
19 | 跨系统实时同步数据,分布式事务是唯一的解决方案吗?
20 | 如何在不停机的情况下,安全地更换数据库?
21 | 类似“点击流”这样的海量数据应该如何存储?
22 | 面对海量数据,如何才能查得更快?
23 | MySQL经常遇到的高可用、分片问题,NewSQL是如何解决的?
24 | RocksDB:不丢数据的高性能KV存储
结课测试 (1讲)
结课测试 | 后端存储,100分试卷等你来挑战
结束语 (1讲)
结束语 | 把奋斗当习惯
后端存储实战课
15
15
1.0x
00:00/00:00
登录|注册

12 | MySQL如何应对高并发(二):读写分离

李玥 2020-03-24
你好,我是李玥。
上节课我和你讲了,使用 Redis 作为 MySQL 的前置缓存,可以帮助 MySQL 挡住绝大部分的查询请求。这种方法对于像电商中的商品系统、搜索系统这类与用户关联不大的系统,效果特别的好。因为在这些系统中,每个人看到的内容都是一样的,也就是说,对后端服务来说,每个人的查询请求和返回的数据都是一样的。这种情况下,Redis 缓存的命中率非常高,近乎于全部的请求都可以命中缓存,相对的,几乎没有多少请求能穿透到 MySQL。
但是,和用户相关的系统,使用缓存的效果就没那么好了,比如说,订单系统、账户系统、购物车系统等等。在这些系统里面,每个用户需要查询的信息都是和用户相关的,即使是同一个功能界面,那每个人看到的数据都是不一样的。
比如说,“我的订单”这个功能,用户在这里看到的都是自己的订单数据,我打开我的订单缓存的数据,是不能给你打开你的订单来使用的,因为我们两个人的订单是不一样的。这种情况下,缓存的命中率就没有那么高,还是有相当一部分查询请求因为命中不了缓存,打到 MySQL 上。
那随着系统用户数量越来越多,打到 MySQL 上的读写请求也越来越多,当单台 MySQL 支撑不了这么多的并发请求时,我们该怎么办?
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《后端存储实战课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(25)

  • 李玥 置顶
    Hi,我是李玥。

    这里回顾一下上节课的思考题:

    课后请你想一下,具体什么情况下,使用Cache Aside模式更新缓存会产生脏数据?欢迎你在评论区留言,通过一个例子来说明情况。

    说一种可能产生脏数据的情况:

    使用Cache Aside模式来更新缓存,是不是就完全可以避免产生脏数据呢?也不是,如果一个写线程在更新订单数据的时候,恰好赶上这条订单数据缓存过期,又恰好赶上一个读线程正在读这条订单数据,还是有可能会产生读线程将缓存更新成脏数据。但是,这个可能性相比Read/Write Through模式要低很多,并且发生的概率并不会随着并发数量增多而显著增加,所以即使是高并发的场景,这种情况实际发生的概率仍然非常低。

    既然不能百分之百的避免缓存的脏数据,那我们可以使用一些方式来进行补偿。比如说,把缓存的过期时间设置的相对短一些,一般在几十秒左右,这样即使产生了脏数据,几十秒之后就会自动恢复了。更复杂一点儿的,可以在请求中带上一个刷新标志位,如果用户在查看订单的时候,手动点击刷新,那就不走缓存直接去读数据库,也可以解决一部分问题。
    2020-03-24
    4
    11
  • Aliliin
    在上家公司,我记得我写订单支付成功之后需要送优惠券的业务,也导致赠送优惠券不成功。
    测试环境怎么都不出问题,后来才想到的是主从的问题,之后就修改成功了,从主库查询并增加优惠券。忙到半夜。这个课程真是太好了。
    2020-03-24
    9
  • 夜空中最亮的星(华仔)
    电商直接提示,订单稍后查询😄
    2020-03-24
    6
  • Mongo
    - Redis作为 MySQL前置
      针对类似电商类看到的结果是一样的效果很好
      针对看到的内容各不相同的时候,效果一般
    - MySQL 针对高并发方案
      - 分布式存储系统难点
          写难以保证数据一致性
          分布式读相对简单
      - 构建分布式集群
        不建议构建分布式集群,代价大
      - 读写分离方案
        读写分离,可有效分担大量的查询请求
        读写分离,实施比较方便
        - 读写分离方案
          部署一主多从多个 MySQL 实例,并让他们之间保持数据实时同步
          分离应用程序对数据库的读写请求,分别发送到从库和主库
          - 分离读写的方法(推荐第二种)
            1.纯手工方式:修改应用程序 DAO 层代码,定义读写两个数据源,指定每一个数据库请求的数据源
            2.组件方式:也可以使用像 Sharding-JDBC这种集成在应用中的第三方组件来实现,这些组件集成在你的应用程序内,代理应用程序的所有数据库请求,自动把请求路由到对应数据库实例上
            3.代理方式:在应用程序和数据库实例之间部署一组数据库代理实例, 比如 Atlas 或者 MaxScale。对应用程序来说,数据库代理把自己伪装成一个单节点的 MySQL 实例,应用程序的诉讼有数据库请求被发送到给代理,代理分离读写请求,然后转发给对应的数据库实例。
          - 配置多个从库
            推荐使用"HAProxy + Keeplived"组合
        - 读写分离弊端
          可能导致数据不一致的问题,正常不超过1ms
          - 解决方法
            将同步的一些操作放到一个数据库事务中来做,写与读在一个库
            增加一些步骤操作,让 1ms 的同步自然的消耗掉
    2020-03-27
    5
  • kyll
    原来用mycat,现在我们使用sharding-jdbc,配置简单,对开发透明。而且看官网上未来发展前景不错。sharding可以做到同一个线程内更新后的查询在主库进行,其他的情况也是在交互上做改进了
    2020-03-25
    3
  • 怀朔
    现在主流的都是用proxy的

    主备延迟怎么解决呢?
    1、开启半同步方案
    2、尽量在主库里面减少大事务、使用不均匀的话开启写后考虑主库读
    3、有能力的话 分库分表
    4、增加从库性能
    5、如果实在无法追平 从新做从库吧
    2020-03-24
    3
  • Mq
    我们系统现在从库没有ha的配置,在检测到主从延迟大于几秒后或故障后,把数据源自动切换切换到主库,如果检测一段时间延长减少又把数据源切换到从库,这种方式目前还行,如果并发真上来了,然后主从同步延迟加大导致切换到主库,可能把主库也搞挂。
             缓存有2层,一层是渠道端,策略是我们有更新了发mq消息通知他们删除,一层是我们系统在有导致数据变更的接口调用后会刷缓存,策略是查主库把数据弄到缓存,另外就是设置缓存失效时间,在回到看数据的页面也要几秒,这种针对活跃的数据有较好的效果,不活跃的数据也没有数据延迟的问题
    2020-03-24
    3
  • 闫冬
    李老师 主从延迟时间比较短的情况 可以在设计上解决 如果延迟时间比较长呢
    2020-04-15
    1
  • zgscy100
    老师您好!读写分离后,是否可以满足高并发写呢,比如秒杀系统,能够满足瞬间大量订单创建写数据库吗?

    作者回复: 即使做了读写分离,一般也不会用MySQL直接抗秒杀请求,还是需要前置保护机制,避免大量的请求打到MySQL上。

    2020-04-05
    1
  • 木头发芽
    阿里云的rds自带读写分离功能,连接数据库是一个url,它通过分析sql语句来决定,更新和事务路由到主库,读写到只读从库,对开发来说无感知,运维只要根据压力情况增加或减少主从节点就好。
    但老师是不是没有说当单表量太大的时候,读写分离并不能解决压力问题,还得分库
    2020-03-29
    1
  • Regis
    我们公司web开发才刚刚起步,主要公司内部使用,还用不到读写分离,不过老师讲的很透彻,终于知道为什么有些网站支付后会有几秒等待才会返回结果了
    2020-03-26
    1
  • leslie
    HAProxy+Keepalived这套架构:挺好挺稳定,业界使用率很高。
    偷懒点可以直接用云厂商,不过读写分离的能力确实不敢恭维。
    2020-03-25
    1
    1
  • 观弈道人
    京东那么大数据量,数据应该还是要分片的,没法避免
    2020-03-24
    1
  • 小美
    对于可能存在主从延迟的地方可以采取强制读主库的措施。
    2020-03-24
    1
  • 写后读,走主库
    2020-03-24
    1
  • 刘楠
    我们公司用的代理的方式,主从延迟,更新完即读的场景不多,强制读主库解决的,
    2020-03-24
    1
  • 王佳山
    这篇文章中提到的同一个事务会路由到主库是什么意思?

    作者回复: 比如先后执行一条更新语句,和一条查询语句。

    默认读写分离的情况下,更新语句会走主库,查询语句会走从库。

    如果把这两条语句放到同一个事务里面,因为事务的原子性,那查询语句也会走主库。

    2020-06-15
  • seg-上海
    业务qps一般到什么水平就要读写分离了,上来就设计成读写分离可以吗
    2020-05-14
  • 被过去推开
    公司的业务量不是很大,采用了两个数据源,用aop的方式动态切换数据源
    2020-04-26
  • 王杰
    一般是数据分片,加读写分离,对于那些实时要用的放到同一个数据库事务中去,相当于部分的读也是用的主库
    2020-04-18
收起评论
25
返回
顶部