老男孩 置顶2019-10-09我觉得进入演进篇以后干货越来越多了。关于理论基础大家都能泛泛的谈一谈，可具体落地实操，老师的经验和能力就体现出来了。关于读写分离，主从同步延时出现的诡异现象，我之前也遇到过。我之前项目最开始没有只是配置了2个数据源，由开发人员选择写主库，读存库。后来发现很多读操作也放到主库上了，理由就是在一些场景下会出现诡异的数据不一致。于是，使用了mycat做代理，开发是比以前方便了，但诡异问题依然存在，又换成了atlas，还是不行。就如同老师说的一样，在没有完全深入了解组件的情况下贸然使用，本来是玩组件，结果被组件玩了。没办法，只好把查询放到一个事务里边，这样代理就会去主库中执行，但这样无异于还是增加的主库的压力。老师在专栏中提供基于消息队列和缓存的方案给我很好的启发，期待后续更多干货。 2 14
2019-10-08给主从复制增加延迟告警的思路很好，另外，老师能具体讲解下QPS和TPS的区别？网上查询了很多资料没有权威的解释。感谢！打卡08作者回复: 我理解的QPS是每秒查询数，是针对读请求的
TPS是每秒执行事务数，倾向于写请求 3 7
2019-10-06总结
1 主从原理：主库通过同步binlog到从库，relaylog去读
2 从库有延迟可以通过缓存 冗余数据来解决
3 4核8g TPS 500 QPS 10000作者回复: 👍
7
2019-10-04Kafka的数据会保存到leader副本的log文件中并写入磁盘，随后follower副本会对数据进行同步 3 7- 2019-10-08平常使用的redis也是用复制的方式 来保持数据同步。redis是以2.8版本为分界。2.8版本之前用用的是性能较差的复制和命令传播。首先是从服务器发生同步操作sync，主服务器会执行bgsave生成一个全量文件的rdb文件 然后传输给从服务器。同时主服务器会把这一过程中执行的写入命令写入缓存区。从服务器会把rdb文件进行一次全量加载。加载完毕后 主服务器会把缓存区中的写入命令传给从服务器。从服务器执行命令后 两个服务器的数据就一致了。
这种方式每次如果网络出现故障 故障重连后都要进行全量数据的复制。对主服务器的压力太大 也会增加主从网络传输的资源消耗。
redis2.8版本之后优化了这一部分缺陷 增加了部分重同步功能。部分同步就是同步故障后的一部分数据 而不是全量数据。这种优化在量级非常大的情况下 提生的效率是相当客观的。 1 4 
2019-11-01之前发生过的一个问题，用Redis主从同步，写入Redis的数据量太大，没加频次控制，导致每秒几十万写入，主从延迟过大，运维频频报警，在主库不挂掉的情况下，这样大量写入会不会造成数据丢失？作者回复: 之前遇到过 如果主从延迟很大，数据会堆积到redis主库的发送缓冲区，会导致主库oom
1 3
2019-10-29老师，为啥优先读写分离，然后再缓存呢，是从那方面考虑的呢作者回复: 从开发和维护的难度考虑。引入缓存会引入复杂度，你要考虑缓存数据一致性，穿透，防雪崩等问题，并且也多维护一类组件
2 3
2019-10-10“在 4 核 8G 的机器上运 MySQL 5.7 时，大概可支撑 500 的 TPS 和 10000 的 QPS”，老师，可以介绍下，挂了几个读库后（比如3个），同样的机器配置，QPS能上升到多少？作者回复: 理论上是三倍，取决于从库的负载均衡是否均匀，另外这个是benchmark结果，只是给大家一个感性认识，实际项目要比这个量极小
1 3
2019-10-10主库宕机之后，binlog丢失导致的主从数据不一致是不是只能手动恢复？作者回复: 在我来看是的
3- 2019-10-10个人感觉中间件不是什么地方都需要高可用 得看具体的业务场景。大多的缓存场景 并发不是很高的话 可以容忍暂时穿透查库。但是一些涉及到业务逻辑的地方 就必须高可用了
作者回复: 可用性是是否容忍故障，如果穿透不会引发故障，是可以的
2 
2019-10-09请问一下来时，通过缓存来抗住高并发的读请求和通过MySQL的读写分离来抗高并发他们之间的区别在哪里呢？分别有哪些适用的场景？作者回复: 优先用读写分离，扛不住了再考虑缓存
3 2
2019-10-04老师讲得很好！案例说到主从的延迟时间预警，未能详细到如何通过哪个数据库中的哪个指标来判别？经验中，我记得是，在从从库中，通过监控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位置
2
2019-10-04主从分离的，如果主节点写入sql,后面同步到从节点，那个时候，从节点实际上即在执行写，也在支持读。那主从分离的作用是保证主节点正常写？其他从节点只是通过增加机器来分担读数据io吗作者回复: 是的
1 2- 2019-11-27老师你好，我以前想要给公司分库分表，后来觉得有几个问题放在我面前，就搁浅了，现在只是挂了一个从库。
最主要的问题：我们公司每天产生许多业务订单，如果以用户id进行hash计算，分发到不同的库，对前台用户订单查询有利，但后台系统页面需要查看全部订单，以倒序排列，这样子的sql会不会执行很慢，毕竟是订单分散到几个库了。老师有好的分库分表方案吗？作者回复: 后台系统不能直接查询分库分表的数据，可以把数据同步到单独的一个后台库中，或者同步到es里面
2 1 
2019-10-30老师你好数据库的qps可以使用什么工具来监控作者回复: open falcon
1
2019-10-24看完就想起来自己之前写async replication的场景。。。简直太折磨。。。 1- 2019-10-15那请问老师缓存和主从分离可以一起使用吗？有没有什么场景？
作者回复: 当然要一起使用了优先主从分离，如果多个从库扛不住再考虑缓存
1 
2019-10-092. 主从的延迟问题，很多诡异的读取不到数据的问题都可能会和它有关，如果你遇到这类问题不妨先看看主从延迟的数据。
请问一下，如果出现了延迟较大导致从库读不到数据，怎样在代码层面一劳永逸地解决呢？谢谢老师～作者回复: 文章中有提到的，三种方案
1. 把数据都传过来，不查数据库
2. 中缓存，从缓存读
3. 直接读主库 4 1
2020-01-21老师你好，我想讲我之前的一个面试，面试官问存储层的高可用怎么搞。
我是这么回答的：存储用最熟悉的MySQL，架起主备，主备前用keepalive + VIP漂移，可以达到秒级切换。主从复制选用半同步复制，保证数据从binlog传输到备库后再返回请求。当主库发生异常时，需要切换，但需要备库应用完本地的relay log后才能成为主库。在这之前不能写，读的话会有少量不一致性。
面试官说：半同步复制可能延时有点大，而且你还相当于“停服”了。说说改成异步复制呢？
我针对异步复制，先分析了一下当主库挂的时候，可能会丢失一些数据。这个时候可以立即切换到备库成为主库，但影响是原主库挂之前一些提交的事务都丢失了，对于业务来说可能表现成用户做了某件事但结果却没做，比如支付了订单但后来发现没有该订单，而且余额也没少。这个时候要做好产品上的公告，表明事故以及让用户重新支付等。而且原主库要做好binlog上跳过那些跟原备库（现在的主库）不一致的部分。但这个方案依然需要等待备库应用完本地的relay log完毕才能切，只要没有长事务，一般很快。
面试官又在更高机房的层次上，提出让我设计一个方案，做到一定的“可伸缩”性，。比如A机房挂了，流量切到B机房，机房可以做到一变二，二变三等，这个时候系统的实战细节等。
这个地方我实在缺乏经验，我的回答是这样的：如果启用多个机房分别服务不同的用户群，想要达到流量切换，势必需要互相同步数据，但这里有个时间窗口不一致的问题，如果A机房挂了，马上切给B，依然采用刚才的思路，没有同步过来的数据算作“没有产生过”，业务有损。这样起码可以保证数据本身的一致性。
上面的三条回答面试官有些不满意，就结束了面试。老师您能帮我看看评价一下我的回答，看是否还有更好的方案？展开作者回复: 其实我觉得对于数据库切换的回答是没有啥问题的
多机房最主要的是数据的用户延迟，一般会自建一些工具
2020-01-13第一次使用主从的时候碰到了主从延时，那时候就感觉很奇怪，明明很简单的数据更新/插入，查询却查不到。
哈哈，后面这种情况又经历了几次，好歹能第一时间发现问题所在了作者回复: 是的，第一次遇到会觉得很诡异