MySql教程

MySQL:为什么要搭建一套MySQL主从架构

本文主要是介绍MySQL:为什么要搭建一套MySQL主从架构,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

MySQL主从架构作用

在MySQL真正的生产环境中,他一定不是一个单机版的架构,因为单机版的MySQL一般仅能用于本地开发环境和测试环境,是绝对不可能运用于生产环境的。

实际生成环境中,MySQL必须搭建一套主从复制的架构,同时基于一些工具实现高可用架构,另外如果有需求,还需要基于一些中间件实现读写分离架构,最后如果数据量大,还必须实现分库分表架构。

MySQL的主从复制架构,这个主从复制架构,顾名思服务器,每台服务器上都得有一个MySQL,其中一个MySQL是master(主节点),另外一个MySQL是
slave(从节点)。然后系统平时连接到master节点写入数据,当然也可以从里面查询了,就跟用一个单机版的MySQL是一样的,但是master节点会把写入的数据自动复制到slave节点去,让slave节点可以跟master节点有一模一样的数据,如下图所示:

在这里插入图片描述
上图其实就是一个典型的MySQL的主从复制架构,那么做这个主从复制架构,意义在哪儿呢?其实这个架构用处是极为多的,一 一举例,首当其冲的一个需求就是高可用架构。

如果MySQL就单机部署,那么一旦它宕机了,岂不是你的数据库就完蛋了?数据库完蛋了,你的Java业务系统是不是也就完蛋了?所以说,真正生产架构里,MySQL必须得做高可用架构。

那么高可用架构怎么做呢?它的一个先决条件就是主从复制架构。必须得让主节点可以复制数据到从节点,保证主从数据是一致的,接着万一你的主节点宕机了,此时可以让你的Java业务系统连接到从节点上去执行SQL语句,写入数据和查询数据,因为主从数据是一致的,所以这是没问题的,如下图所示:
在这里插入图片描述
如果实现这样的一个效果,自然就实现了MySQL的高可用了,它单机宕机不影响你的Java业务系统的运行。但是也得注意,这里其实是没这么简单的,因为实际哪怕这套架构运用到生产环境,也是有大量的问题要解决的。

比如主从进行数据复制的时候,其实从节点通常都会落后一些,所以数据不完全一致。另外,主节点宕机后,要能自动切换从节点对外提供服务,这个也需要一些中间件的支持,也没那么容易。

如果做了这个MySQL主从复制架构之后,除了这个高可用之外,还有什么作用呢?其实这就得说到大名鼎鼎的读写分离架构了!这个读写分离架构,也是依赖于MySQL的主从复制架构的。

读写分离架构的意思就是,Java业务系统可以往主节点写入数据,但是从从节点去查询数据,把读写操作做一个分离,分离到两台MySQL服务器上去,一台服务器专门写入数据,然后复制数据到从节点,另外一台服务器专门查询数据,如下图所示:
在这里插入图片描述
可是好端端的,吃饱了没事儿,为什么要做读写分离呢?难道就为了好玩儿吗?当然不是了!因为假设MySQL单机服务器配置是8核16GB,然后每秒最多能抗4000读写请求,现在假设真实的业务负载已经达到了,每秒有2500写请求+2500读请求,也就是每秒5000读写请求了,那么如果都放一台MySQL服务器,能抗的住吗?

必然不行啊!所以此时如果可以利用主从复制架构,搭建起来读写分离架构,就可以让每秒2500写请求落到主节点那台服务器,2500读请求落到从节点那台服务器,用2台服务器来抗下每秒5000的读写请求,如下图所示:
在这里插入图片描述
接着现在问题来了,其它大部分Java业务系统都是读多写少,读请求远远多于写请求,那么接着发现随着系统日益发展,读请求越来越多,每秒可能有6000读请求了,此时一个从节点服务器也抗不下来啊,那怎么办呢?

简单!因为MySQL的主从复制架构,是支持一主多从的,所以此时可以再在一台服务器上部署一个从节点,去从主节点复制数据过来,此时就有2个从节点了,然后每秒6000读请求不就可以落到2个从节点上去了,每台服务器主要接受每秒3000的读请求,如下图:
在这里插入图片描述
如上图,Java业务系统每秒以2500的TPS写入主库,然后主库会复制数据到两个从库,接着每秒6000 QPS的读请求分散在两个从库上,一切似乎很完美,这就是主从复制架构的另外一个经典的应用场景,就是读写分离,通过读写分离,可以抗下很高的读请求。

而且在上述架构之下,还可以融合高可用架构进去,因为有多个从库,所以当主库宕机的时候,可以通过中间件把一个从库切换为主库,此时Java业务系统可以继续运行,在实现读写分离的场景下,还可以同时实现高可用。

不过其实一般在项目中,高可用架构是必须做的,但是读写分离架构并不是必须的,因为对于大多数公司来说,读请求QPS并没那么高,远远达不到每秒几千那么夸张,但是高可用你是必须得做的,因为你必须保证主库宕机后,有另外一个从库可以接管提供服务,避免Java业务系统中断运行。

除此之外,这个从库其实还有很多其它的应用场景,比如可以挂一个从库,专门用来跑一些报表SQL语句,那种SQL语句往往是上百行之多,运行要好几秒,所以可以专门给它一个从库来跑。也可以是专门部署一个从库,去进行数据同步之类的操作。

MySQL主从架构实现原理

  • MySQL在执行增删改的时候会记录binlog日志,这个binlog日志里就记录了所有数据的增删改的操作。如下图:
    在这里插入图片描述

  • 然后从库上有一个IO线程,这个IO线程会负责跟主库建立一个TCP连接,接着请求主库传输binlog日志给自己,这个时候主库上有一个IO dump线程,就会负责通过这个TCP连接把binlog日志传输给主库的IO线程,如下图:
    在这里插入图片描述

  • 接着从库的IO线程会把读取到的binlog日志数据写入到自己的本地relay日志文件里去,然后从库上另外有一个SQL线程会读取relay日志里的内容,进行日志重做,把所有在主库执行过的增删改操作,在从库上做一遍,达到一个还原数据的过程。如下图:

在这里插入图片描述

总的来说,只要给主节点挂上一个从节点,从节点的IO线程就会跟主节点建立网络连接,然后请求主节点传输binlog日志,主节点的IO dump线程就负责传输binlog日志给从节点,从节点收到日志后就可以回放增删改操作恢复数据

这篇关于MySQL:为什么要搭建一套MySQL主从架构的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!