12 | MySQL如何应对高并发（二）：读写分离

Hi，我是李玥。 这里回顾一下上节课的思考题： 课后请你想一下，具体什么情况下，使用Cache Aside模式更新缓存会产生脏数据？欢迎你在评论区留言，通过一个例子来说明情况。 说一种可能产生脏数据的情况： 使用Cache Aside模式来更新缓存，是不是就完全可以避免产生脏数据呢？也不是，如果一个写线程在更新订单数据的时候，恰好赶上这条订单数据缓存过期，又恰好赶上一个读线程正在读这条订单数据，还是有可能会产生读线程将缓存更新成脏数据。但是，这个可能性相比Read/Write Through模式要低很多，并且发生的概率并不会随着并发数量增多而显著增加，所以即使是高并发的场景，这种情况实际发生的概率仍然非常低。 既然不能百分之百的避免缓存的脏数据，那我们可以使用一些方式来进行补偿。比如说，把缓存的过期时间设置的相对短一些，一般在几十秒左右，这样即使产生了脏数据，几十秒之后就会自动恢复了。更复杂一点儿的，可以在请求中带上一个刷新标志位，如果用户在查看订单的时候，手动点击刷新，那就不走缓存直接去读数据库，也可以解决一部分问题。

这篇文章中提到的同一个事务会路由到主库是什么意思？

老师您好！读写分离后，是否可以满足高并发写呢，比如秒杀系统，能够满足瞬间大量订单创建写数据库吗？

HAproxy keepalived是和mysql部署在同一台机器上的吗？还是部署在单独的机器上的？

在上家公司，我记得我写订单支付成功之后需要送优惠券的业务，也导致赠送优惠券不成功。 测试环境怎么都不出问题，后来才想到的是主从的问题，之后就修改成功了，从主库查询并增加优惠券。忙到半夜。这个课程真是太好了。

- Redis作为 MySQL前置 针对类似电商类看到的结果是一样的效果很好 针对看到的内容各不相同的时候，效果一般 - MySQL 针对高并发方案 - 分布式存储系统难点 写难以保证数据一致性 分布式读相对简单 - 构建分布式集群 不建议构建分布式集群，代价大 - 读写分离方案 读写分离，可有效分担大量的查询请求 读写分离，实施比较方便 - 读写分离方案 部署一主多从多个 MySQL 实例，并让他们之间保持数据实时同步 分离应用程序对数据库的读写请求，分别发送到从库和主库 - 分离读写的方法(推荐第二种) 1.纯手工方式：修改应用程序 DAO 层代码，定义读写两个数据源，指定每一个数据库请求的数据源 2.组件方式：也可以使用像 Sharding-JDBC这种集成在应用中的第三方组件来实现，这些组件集成在你的应用程序内，代理应用程序的所有数据库请求，自动把请求路由到对应数据库实例上 3.代理方式：在应用程序和数据库实例之间部署一组数据库代理实例， 比如 Atlas 或者 MaxScale。对应用程序来说，数据库代理把自己伪装成一个单节点的 MySQL 实例，应用程序的诉讼有数据库请求被发送到给代理，代理分离读写请求，然后转发给对应的数据库实例。 - 配置多个从库 推荐使用"HAProxy + Keeplived"组合 - 读写分离弊端 可能导致数据不一致的问题，正常不超过1ms - 解决方法 将同步的一些操作放到一个数据库事务中来做，写与读在一个库 增加一些步骤操作，让 1ms 的同步自然的消耗掉

原来用mycat，现在我们使用sharding-jdbc，配置简单，对开发透明。而且看官网上未来发展前景不错。sharding可以做到同一个线程内更新后的查询在主库进行，其他的情况也是在交互上做改进了

电商直接提示，订单稍后查询😄

HAProxy+Keepalived这套架构：挺好挺稳定，业界使用率很高。 偷懒点可以直接用云厂商，不过读写分离的能力确实不敢恭维。

现在主流的都是用proxy的 主备延迟怎么解决呢？ 1、开启半同步方案 2、尽量在主库里面减少大事务、使用不均匀的话开启写后考虑主库读 3、有能力的话 分库分表 4、增加从库性能 5、如果实在无法追平 从新做从库吧