数据库——MySQL读写分离后的延迟解决方案
背景:
根据上图可以看到QPS:10.73k,实际上真实的并发大量数据到达的时候,我这里最高的QPS是将近15k.而目前单个数据库分片(实例)4CPU8G内存的配置下,最高的性能是7k的QPS。
基于上篇我进行了分库分表是对于性能有很大的提高,分库分表实践和中间件的引申
我这里讲解的例子是目前4主8从库(12个实例),以下每个实例都会称为分片。单个分片配置mysql版本5.7.19(一会说明不同版本是读写分离的不同策略),12CPU16G内存,128G的磁盘,Raid:10。
读写分离实践
读写分离可以参考上篇文章的分库分表实践中的中间件的用法来实现。主流一般会使用mycat,但是每个中间件都有自己的优点可以择优和业务特点而用。接下来讲读写分离后的后遗症。
读写分离的延迟和实时insert/update和查询操作
比如我这里的一个场景:由于数据量大,以人维度的情况下,商品量20w~50w。然后需要分页查询未同步下游状态,进行数据同步后再更新该分页数据。我当时设定了如下的四种场景,最后选择了读写分离和不分离同时存在,针对于实时要求结果高的依然是master主库读写,变动需求量小的数据,全部转移slave从库。
如下是四种场景的方案:
1、 完全分离:全量读->从库,全量读写->主库
前提:第一页查询逻辑不变
特点:半同步复制,目前是1主2从库,利用半同步复制原理,1/2的可能性会重复查询,当然这个几率需要和延时性进行测试计算可得,也就是最坏的结果可能性是重复查询50%的可能