00:00
接下来我们就以MYS狗为例,说一下它的这个集群方案,我们先来看一下MYS狗的集群原理,先看这张图,这个MYS狗集群呢,市面上有非常多的解决方案,我们就来说上两三种,大概给大家看一下,首先第一种叫马SQLMMM,这个呢就是我们说的master master replication manager,就是我们的主,主复制管理器,它这种方式呢,可以来搭建一个马SQ集群,那这种方式是什么样子的?首先我们看到两个关键词,就是主,主,然后呢再加上复制,所以它整个架构呢是这个样子,它呢,首先里边呢有一个monitor叫监控器,监控器呢,假设我们现在三个把,一个呢叫MASTER1,一个叫MASTER2,一个叫slave,这这个呢就是主,这个是主,那这个是从在我们这种架构下,从节点呢,只是来复制主节点数据的。
01:00
那这样我们这两个主节点又有什么用呢?我们来看现在这个主节点啊,肯定只有一个主节点,目前呢是真正的主节点生效的,但是呢,这个主节点是来作为一个备用主节点,所以我们现在的这个架构师,如果在没有故障情况下是一主两,从而我们这个MMM架构是利用一个监控器,它为了能达到我们这个失败的这个容错,它利用一个监控器,然后呢为我们三个MYSQL,首先呢,我们会创建一个东西叫VIP,就是虚拟IP集,相当于假设我给三个MY色Q创建一个虚拟IP,比如这个呢是0.1,这个是0.2,这个呢是0.3,啊前面我们就不管了,然后呢,我们现在是0.1 0.2 0.33个马色扣,那0.1呢,现在是主码S扣,他呢,拥有一个虚拟IP,但这个IP只能是用来写的。
02:00
也就是如果我们客户端想要给MYSQ里边增删改数据,那么就连上这个MYSQ,如果想要读,那就连上我们这个0203这两个MYSQL,然后呢,相当于我们客户端明确的知道有三个IP,然后呢,第一个IP是用来写数据的,第二个IP我们可以来进行读,所以呢,它相当于做了一个读写分离,那么想要读数据呢,去这两个MYSQL,想要写去这然后呢,这两个MYSQL我们看到都是呢,先会跟我们的master来进行一个复制,这样话我们这个压力就分担了,那就是我们基本的这个主从式主从复制分担压力的方式,但如果出现问题怎么办?它的这个核心就在这三个IP上,这三个IP呢,是monitor来帮我们做的虚拟IP的这个监控,然后接下来假设MASTER1宕机了以后,那MASTER1的这个写IP写IP呢。
03:00
它就会被我们的这个mon拿过来,然后呢交给MASTER2,相当于MASTER2的这个写IP master2呢,现在拥有一个读IP,好拥有一个写IP,我们就要把写IP呢交给这一块呢,相当于我们说这块做了一个IP的漂移,诶我们把他的这个IP飘到这儿,所以你的客户端连着看的你的IP不变,但实际上呢,已经换了另外一台机器,那就是由这个monitor来帮我们来做的,只要有任何问题,他呢将这些虚拟IP就是来回进行漂移,而且呢,由于我们这个备选master节点之前呢,是一个作为从节点的方式,所以呢,他现在呢,相当于跟我们的主马s master是拥有一个同样的数据的,当然一旦它这个中断,可能有一部分数据没同步过来,所以它会有我们数据的一致性,相关的这个问题,但是呢,我们解决了我们两个主之间的这个高考用问题,我们把这个主I。
04:00
飘移在这儿,那下一次master再启动了,那么它就会再作为一个重节点来去同步我们的现有的这个master的数据,所以我们这一周呢,就叫双主复制,两个主节点呢,都在这儿复制,那下一次呢,一个主节点当宕机,另外一个主节点提升为我们真正的主节点,下次进来他再同步我们这个我们的这个MMM机制中间的这个monitor,他呢就是负责来监听。我们这三个节点,然后呢,每一个节点里边都有我们这个monitor的代理,然后我们这个monitor相当于维护一个虚拟IP的这个映射表,然后呢,最终的这个虚拟IP最终就会漂移过去,这是我们说的这个MM机制,还有一个MHA机制,这我们称为叫master的这个高可用机制,它呢也能做到故障切换,主要是来靠把我们的这个从节点而不是候选主节点,把它提成提升成我们的这个主节点,这个呢大家了解一下,然后呢我们来说一个这个应no DB class这个东西呢,是我们my circle现在官方支持的一种集群方式,这种集群方式呢,也有非常多的好的特性,比如我们可以自动的容错,然后呢,我们的这个强一致性,读写分离,读库的高可用等等等等,我们横向扩展呢,也非常容易,我们这种方式呢,它是由我们三个组件来配合起来完成。
05:31
我们整个集群的度DB集群这三个组件呢,分别叫MySQL shell,还有的MySQL routeta,以及我们MYSQL真正的服务器集群,那这三者是什么样的关系?首先MySQL share,它是呢,提供给我们管理员管理我们整个MYSQL的一个客户端,相当于我们不用以前MYSQL非集群情况下的那种自带客户端了,用mysq share由管理员来管嘴里我们诊断MYSQL集群,但如果我们自己要在MYSQL里边读写数据怎么办?所以接下来我们自己呢,通过我们的这个MYSQL连接器,比如我们这些JDBC之类的驱动们想要连马SQL集群,连的呢,其实不是集群,而是我们提供的一个叫MySQL root,这个root呢,我们看到这是一个路由器,这个路由器的作用就是可以根据我们集群里边部署的这些。
06:31
些情况,他呢自动的来初始化它的这个实力,然后呢,他的这个实力是我们其他客户端连接的是他,而不是我们集群里边的其他节点,那然后呢,我们想要对集群里边的任何读写操作,我们呢都连给他,然后呢他去来调度对集群里边来进行读写,但是呢,现在如果出现了我们整个问题。如果我们在单主模式下,我们现在看到集群里边有一个primary主,还有我们的second这两个从节点,这个主呢是RW可读可写的,从节点呢是read only,只是只读情况的,所以我们的读写请求呢,只要是写交给主,然后呢读我们可以从从里边来进行读,那一旦我们出现节点的宕机,我们整个集群呢,全部都会自动的更新配置,想在整个集群内会发生一些变化,然后变化完了以后,我们这个mys route它呢就会自动的探测到我们这些集群里边的变化,所以我们这个马S狗其他人呢,连接这个rota想要操作的时候,他已经监听到这个变化了,所以呢,对着我们之前的这些操作,比如这个主已经荡掉了,他呢,挑出一个提升为我们新的这个写入数据的这个节点,他荡掉了以后呢,把我们这些请求就会重新转发给我们这。
07:56
这个主节点,比如我们来进行写,这个呢再来进行读,所以呢,我们这个rota整个集群呢,主荡掉以后,从会T上来,我们这个rota实时感知,然后最终把我们整个请求呢,路由到我们真正能进行读写的这个服务器,这是我们说的应DB classluster这种方案,但无论是哪种方案,大家发现了一个共性都就是我们这个不可缺,就是一个主从模式,在MYSQ里边呢,主从同步不可缺,那么主里边的数据从样同步,这样呢能做到我们这个读写分离,读从从里边读,写给主里边写,假设1万个请求,那有我们1000个是写,我们放到主里边,然后呢9000个是读,我们从从里边每个人再来分担4000个,诶,比如或者3000个我们分担到这儿,所以呢,我们现在有了我们这个主存方式,我们读写分离压力能分担,但是主存方式的唯一缺点就是我们主节点的这个数据从节点的同步。
08:56
还是需要一段时间的,但虽然它很快,比如只需要不到我们的十毫秒,20毫秒,但是呢,我们会有一定数据量的延迟,如果网络非常不佳的情况下,那么这个延迟呢就会非常大,当然我们都发现了整个储存的影子,但这个储存呢,我们可以用各种方式,如果主断掉以后怎么办?提升从或者呢,给主专门做一个候选的备份等等等等,我们会有非常多的方式来做这个事情。
09:26
这MYSQ的这个集群原理最简单的这个集群以后呢,我们就可以晋升到我们现在企业用的比较多的这种集群解决方案,比如我们企业这个用户,我们无论是商品服务,订单服务,我们都要操作数据库,怎么办呢?我们先来到第一个我们的数据库的代理DB proxy,这个代理呢,可以是大家我们这个以前学的MY,如果没学过的话,我们上硅谷也发布了market相关的课程,你可以用market或者DB proxy来作为我们后端整个马库的一个代理,所以我们想要连我们数据库,相当连的是DB proxy或者market,或者我们接下来要说的JBBC的这一套东西,然后呢,我们连接的是他们,然后连接他们以后,当然他们呢,如果一个节点宕机,你也可以给把这个DB proxy部署上多个节点,然后呢,有一个宕机能切换到另外一个节点,我们来做一个备的方式。
10:27
式,我们来连上我们这代理节点了,将下来我们要读写请求,写呢就交给马克,读呢可以交给从节点,那这样接下来怎么办?如果我们出现了宕机,而从节点呢,它一定是来同步我们主节点的数据的,所以主节点数据从节点都会同步,重节点呢,我们还可以给他进行角色区分,比如123这个从节点就是面向给公众来进行访问的,他们来承担我们这个大兵发量,我们商品的这些访问,比如这个10万请求的,我们来给他每一个均分,但是呢,接下来比如s slave4,我们这个从节点专门是我们的后台管理系统,我们要读取一些数据,我们的读可以从这个从节点里边读,像后台管理系统不会因为我们前端用户流量过大。
11:17
把我们这些存节点都打满以后,我们后台管理系统都没法维护,都读取不到数据,所以有了它以后呢,那相当于后台管理系统可以在我们前端高并发的情况下,我们照样使用,然后再来加一个slave的备份数据,这样如果出现了故障问题,我们这儿还有一个备份节点。所以我们可以有非常多的从节点将它分为不同的角色来进行使用,但无论是怎样,从节点都是从我们的主节点里边同步数据的,但如果主节点又出现了问题怎么办?我们不去来提升从节点,我们可以专门来准备一个备用主节点,如果它出现了问题,我们就来提升到备用主节点,这个备用主节点呢,一开始来同步我们这个主节点的这个数据,只要它出现了问题,我们就把它提升上来。
12:10
然后其他的s slave又去来同步它里边的这个数据,所以这是我们说的这一种,这相当于我们这个双主的复制,然后我们现在呢,来检测我们主节点的这个存活以及切换,这个呢,在我们my circle里边,如果我们不是用应DB class这种模式的话,它以前呢是默认没提供这种机制的,我们得结合一些第三方技术,比如keep alive。来检测我们的这个存活,我们来进行热热备份,如果一个不行呢,用另一个来顶上来,所以呢,我们很多种这个解决方案都是要基于people I来进行一个存活检查来做的热备份,这是我们说的这种方案,但无论怎么一种方案,我们引入这个people I alive也好,但我们现在呢,最终都是来做的一个主从,那这个主从呢,大家又会发现一个问题,就是我们节点的容量数据提升不了,相当于我们一个主节点到底能保存多少个数据,是由我们当前这个服务器决定的,如果我们想要再大的提升数据量,我们呢,可以对MYSQL的数据来进行分片存储,比如我们这个mask就是来保存这个一到1万的数据的,这个是保存两到2万的,那每一个分片呢,又可以做成这种模式,但是呢,MYS,因为它的数据一般最终呢,都会持久化到我们的磁盘里边。
13:36
所以我们这个马赛的数据量跟我们磁盘的这个容量。有很大的关系,一般性想要造成我们单排马S狗这个数据量都存不下这种情况呢,倒是比较少,但是我们单排马S狗数据量一存大以后,比如我们单表存了几千亿个数据,诶磁盘空间是够用了,但数据量一大以后,马S狗L对这张表的整个索引的检索维护,包括我们来查询都会变得超级慢,所以呢,我们后来更多的我们去来把MYSQL分出来,来做到分库分表,是为了提升我们这个MYS狗的检索效率,不让我们这个单表数据量巨大以后,我们的检索效率来下降,但无论怎样,我们先得有一个储存方式来同步这个数据,也能分担压力,也能做备份,那现在呢,就是需要一个主从这MYS狗常见的一些集群,那么下节课呢,就可以先来简单的搭建一个主从同步的这个方式,那后来我们可以结合其他的技术,Keep I alive来做一个双主的这个热备切。
14:40
快,等等等等。但这个后续呢,就是我们其他再来发布的运维部署课程里边来教大家做的事情了,那现在来先来做的一个简单的主从同步,我们来先看一下。
我来说两句