1.为什么进行读写分离
这个,高并发这个阶段,那肯定是需要做读写分离的,啥意思?因为实际上大部分的互联网公司,一些网站,或者是app,其实都是读多写少。所以针对这个情况,就是写一个主库,但是主库挂多个从库,然后从多个从库来读,那不就可以支撑更高的读并发压力了吗?
2.如何实现mysql读写分离
其实很简单,就是基于主从复制架构,简单来说,就是搞一个主库,挂多个从库,然后我们就只是写主库,然后主库自动把数据同步到从库,读数据全都走从库。
3.MYSQL主从复制原理
主库将数据操作指令写到binlog日志,然后从库连接主库之后,从库有一个IO线程,将主库的binlog日志拷贝到自己本地,写入一个中继日志中。接着从库中有一个SQL线程会从中继日志中读取binlog,然后执行binlog日志中的内容,也就是在自己本地再执行一遍SQL,这样就可以保证自己跟主库的数据是一致的。
这里有一个非常重要的一点,就是从库同步主库数据的过程是串行化的,也就是说主库上并行的操作,在从库上会串行执行。现在更高版本mysql,会有更多的5.6并发的线程,但5,6是串行。所有在高并发场景下,从库的数据一定会别主库慢一些,,是有延时的。所以经常出现,刚写入的数据可能是读不到的问题,要经过几十毫秒,甚至几百毫秒才能读取到。
还有一个问题,就是如果一个数据已写入主库,但是这时候binlog从库还没有来得及复制。主库这时候宕机了,那么有些数据可能在从库上是没有的,有些数据就会丢失。
4.解决主库数据丢失问题
mysql有一个机制叫做半同步复制,这个机制就可以解决主库数据丢失问题。
这个所谓半同步复制,semi-sync复制,指的是主库写入binlog日志之后,就会将数据立即强制将数据同步到从库。从库将日志写入自己本地的relay log之后,接着会返回一个ack给主库,主库接收到至少一个从库的ack之后才会认为写操作完成了。
5.解决主从同步延迟
mysql可以在复制binlog文件时并行复制,减轻延迟问题。
这个所谓并行复制,指的是从库开启多个线程(也就是图中的sql线程),并行读取relay log中不同库 的日志,然后并行重放不同库的日志,这是库级别的并行。
MySQL从5.6开始有了SQL Thread多个的概念,可以并发还原数据,即并行复制技术。MySQL 5.6中,设置参数slave_parallel_workers = 4(>1),即可有4个SQL Thread(coordinator线程)来进行并行复制,其状态为:Waiting for an evant from Coordinator。
但是其并行只是基于Schema的,也就是基于库的。如果数据库实例中存在多个Schema,这样设置对于Slave复制的速度可以有比较大的提升。通常情况下单库多表是更常见的一种情形,
那基于库的并发就没有卵用。其核心思想是:不同schema下的表并发提交时的数据不会相互影响,即slave节点可以用对relay log中不同的schema各分配一个类似SQL功能的线程,来重放relay log中主库已经提交的事务,保持数据与主库一致。
在MySQL 5.7中,引入了基于组提交的并行复制(Enhanced Multi-threaded Slaves),设置参数slave_parallel_workers>0并且global.slave_parallel_type=‘LOGICAL_CLOCK’,
即可支持一个schema下,slave_parallel_workers个的worker线程并发执行relay log中主库提交的事务。其核心思想:一个组提交的事务都是可以并行回放(配合binary log group commit);主怎么并行执行,从就怎么并行回放
slave机器的relay log中 last_committed相同的事务(sequence_num不同)可以并发执行。
其中,变量slave-parallel-type可以有两个值:DATABASE 默认值,基于库的并行复制方式;LOGICAL_CLOCK:基于组提交的并行复制方式;
- 推荐:从库配置多线程复制(slave_parallel_workers)的前提是主从开启GTID;
但这不是解决延迟的根本方法,在高并发下,作用不大。
如果有主从延迟,很可能就是代码的问题,比如update后,马上get,这是主从复制架构开发的一个大忌。
6.mysql主从延时问题
show status,Seconds_Behind_Master,你可以看到从库复制主库的数据落后了几ms。
其实这块东西我们经常会碰到,就比如说用了mysql主从架构之后,可能会发现,刚写入库的数据结果没查到,结果就完蛋了。。。。
所以实际上你要考虑好应该在什么场景下来用这个mysql主从同步,建议是一般在读远远多于写 ,而且读的时候一般对数据时效性要求没那么高的时候,用mysql主从同步。
所以这个时候,我们可以考虑的一个事情就是,你可以用mysql的并行复制,但是问题是那是库级别的并行,所以有时候作用不是很大
所以这个时候通常来说,我们会对于那种写了之后立马就要保证可以查到的场景,采用强制读主库的方式,这样就可以保证你肯定的可以读到数据了吧。其实用一些数据库中间件是没问题的。
一般来说,如果主从延迟较为严重
1、分库,将一个主库拆分为4个主库,每个主库的写并发就500/s,此时主从延迟可以忽略不计。
2、打开mysql支持的并行复制,多个库并行复制,如果说某个库的写入并发就是特别高,单库写并发达到了2000/s,并行复制还是没意义。28法则,很多时候比如说,就是少数的几个订单表,写入了2000/s,其他几十个表10/s。
3、重写代码,写代码的同学,要慎重,不要做插入之后立即查询操作,插入数据之后,直接就更新,不要查询。
4、如果确实是存在必须先插入,立马要求就查询到,然后立马就要反过来执行一些操作,对这个查询设置直连主库。不推荐这种方法,你这么搞导致读写分离的意义就丧失了