08 | 数据库优化方案（一）：查询请求增加时，如何做主从分离？

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

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

老师，为啥优先读写分离，然后再缓存呢，是从那方面考虑的呢

之前发生过的一个问题，用Redis主从同步，写入Redis的数据量太大，没加频次控制，导致每秒几十万写入，主从延迟过大，运维频频报警，在主库不挂掉的情况下，这样大量写入会不会造成数据丢失？

老师你好数据库的qps可以使用什么工具来监控

总结 1 主从原理：主库通过同步binlog到从库，relaylog去读 2 从库有延迟可以通过缓存 冗余数据来解决 3 4核8g TPS 500 QPS 10000

给主从复制增加延迟告警的思路很好，另外，老师能具体讲解下QPS和TPS的区别？网上查询了很多资料没有权威的解释。感谢！打卡08

老师你好，我想讲我之前的一个面试，面试官问存储层的高可用怎么搞。 我是这么回答的：存储用最熟悉的MySQL，架起主备，主备前用keepalive + VIP漂移，可以达到秒级切换。主从复制选用半同步复制，保证数据从binlog传输到备库后再返回请求。当主库发生异常时，需要切换，但需要备库应用完本地的relay log后才能成为主库。在这之前不能写，读的话会有少量不一致性。 面试官说：半同步复制可能延时有点大，而且你还相当于“停服”了。说说改成异步复制呢？ 我针对异步复制，先分析了一下当主库挂的时候，可能会丢失一些数据。这个时候可以立即切换到备库成为主库，但影响是原主库挂之前一些提交的事务都丢失了，对于业务来说可能表现成用户做了某件事但结果却没做，比如支付了订单但后来发现没有该订单，而且余额也没少。这个时候要做好产品上的公告，表明事故以及让用户重新支付等。而且原主库要做好binlog上跳过那些跟原备库（现在的主库）不一致的部分。但这个方案依然需要等待备库应用完本地的relay log完毕才能切，只要没有长事务，一般很快。 面试官又在更高机房的层次上，提出让我设计一个方案，做到一定的“可伸缩”性，。比如A机房挂了，流量切到B机房，机房可以做到一变二，二变三等，这个时候系统的实战细节等。 这个地方我实在缺乏经验，我的回答是这样的：如果启用多个机房分别服务不同的用户群，想要达到流量切换，势必需要互相同步数据，但这里有个时间窗口不一致的问题，如果A机房挂了，马上切给B，依然采用刚才的思路，没有同步过来的数据算作“没有产生过”，业务有损。这样起码可以保证数据本身的一致性。 上面的三条回答面试官有些不满意，就结束了面试。老师您能帮我看看评价一下我的回答，看是否还有更好的方案？

文章里说通过冗余数据来解决主从延迟的问题，我有些异议，这种方式会造成缺乏扩展性，消息承载的数据很多消息组件都会有字节大小的限制，这样的话，如果后续数据量随着业务进行了扩展，就难免不会产生问题，持续扩展能力相对较差，我的理解倒是可以通过消息重试的方式来解决这个问题，如果主从同步延迟，那就消息重试，直到数据同步过来即可，这种解决方案通常业务上也是能忍受的，当然还是要按照具体case具体分析

老师讲得很好！案例说到主从的延迟时间预警，未能详细到如何通过哪个数据库中的哪个指标来判别？经验中，我记得是，在从从库中，通过监控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这个值来判断延迟是不够准确的。 不知，还有其他更好的方式？