重视[读写分离]的delay影响

         最近参考了公司的文档，整理了一下读写分离的delay影响。

读写分离

         过去我们几乎都只是宣扬读写分离的好处，往往没有重视由此带来的问题。

         读写分离大大提高了我们系统的读写性能、可扩展性以及高可用性，同时也带来了主从的delay。这个主从delay对不同业务有不同程度的影响，有一些甚至会造成致命的bug，特别是在支付领域，我们不得不重视起来。

         接下来我们讨论一下读写分离的优缺点，在什么情况下可以优先考虑读写分离，怎么样会引起delay，以及delay的一些应对策略。

 

优点

1.        在相对简单的付出下（相对于sharding），解决系统可扩展性的问题。

2.        对读的高可用性和QPS的要求非常高（比如用户登陆和一些配置信息），但降低了对写的高可用性要求，一般读写比率在10:1 以上。

3.        很容易实现读库99.999%的高可用。

4.        降低大查询/报表类应用对在线系统的压力（不鼓励这种用法）。

 

缺点

1.        对开发的要求更高：需要清楚，什么时候读主库，什么时候读从库；要避免写大job和大SQL，否则会引起从库的delay。

2.        需要处理从库delay 的问题：什么时候和什么情况要回源主库？大部分是不应该甚至不能回源的，而且集中回源很容易压死主库。

3.        从库的delay会降低主库的写容量：当主库的TPS超过6k，从库delay就会逐步增加，而主库的TPS其实可以承受1.5w~2w。

 

总体判断

1.        读写比率，必须在10:1 以上（建议20:1以上），才考虑读写分离，不然因此引入的delay会让你得不偿失。例如延迟时候突发的failover，要么抛弃延迟的数据（如果硬件故障，大事务产生的大量bin log来不及传送，必然丢数据），要么等延迟过去拉长了故障恢复时间。

2.        必须在读写分离的读库前，通过LVS虚拟化读库的IP。在10:1的读写比率下，一般读库的压力会大于写库，所以需要多个数据库服务器来支撑，同时LVS可以掩盖和解决后端数据库服务器的维护问题，这样基本上能使读库在逻辑上always online。

3.        读写分离的应用，避免写大job和大SQL，都会引起从库的delay。对于一个transaction最好不要拆分，避免到从库和主库分别查询，因为主从复制必然会带来delay。

4.        读写分离的应用，程序要能够处理delay的情况：必须能够容忍读库delay3~5s，如果不能容忍，请不要连接从库。

5.        读写分离的主库，要设计好支撑的容量：写库3年内可以不用sharding拆分，不然成本太高。

6.        避免读写分离的主库过大（2TB）。

7.        读写分离，不应该作为报表的标准解决方案。在线系统和报表系统，原则上应该分离。MySQL本身也不适合报表类型的应用；报表类型的应用（后端系统较多）应该考虑通过hadoop 来解决。

8.        对于cache侧有可能回源的应用，可以考虑读写分离，所有的读回源都通过LVS。

 

应对delay

         我们应对读写分离的主从delay，分为事前和事后两个阶段：

       事前避免：主要从系统设计层面，在设计的时候就要考虑到，怎么去防御和避免delay，尽量细化操作，避免出现下面的情况 (常见的从库delay原因)。

a)        代码逻辑需要容错性，考虑到delay的情况，因为主从delay是不可避免的。

b)        核心读都放在主库上，避免因为slave延迟导致判断失误；

c)        非核心读，放在从库上，如用户自发的查询：钱包余额，会员信息等。

 

       事后监控：主要通过DBA和APP两个层面的控制：

a)        DBA监控，尽早介入排除故障，实践证明，这里的MTTR需要10分钟到1个小时不等，而且往往需要多部门（DEV, DBA）联动。

b)        APP的检测延迟机制，做心跳表，遇到超过阈值的降级读主库。不过这种模式下，主库的压力就不可预测了。

 

常见的从库delay原因

1.        大job，一个update 几万条记录。

2.        一个update全表扫描地修改多条记录（100+）。因为我们是基于row的复制，每一条都要跑一遍全表扫描，或者低效的索引扫描，性能会很低，而且从库的影响还会放大。

3.        表没有主键，导致从库复制每一条记录的DML都会做全表扫描。

4.        大SQL，比如频繁的大量的复杂join，很容易耗尽IO和CPU，造成从库的严重delay。

5.        DBA的维护操作，如大表的onlineDDL，或者归档的job。要注意分散数据库的压力，控制好online DDL和归档的速度和并发，避免两者同时进行。

6.        网络或者系统问题：跨机房/同机房的网络不稳定，系统不稳定（机器故障）等。

7.        MySQL bug，引起复制中断。

8.        频繁对Text字段的表的读写，容易把IO耗光，哪怕是flash卡。

9.        一些框架，查询也会发起事务，如set autocommit=0，然后select，最后又不关闭连接，到发布需要做DDL变更时，就会导致表锁，从而delay。