引言

内容为慕课网的《高并发高性能高可用 Mysql 实战》视频的学习笔记内容和集体整顿扩大之后的笔记，这一节讲述三高架构的另外两个局部切换和扩大，扩大指的是分库分表加重数据库的压力，同时因为分库分表须要针对节点宕机问题引入了一些优化伎俩，而切换局部就是讲述节点宕机的切换问题的，最初咱们联合复制的主从切换讲述如何搭建一个三高的架构。

如果内容比拟难能够追随《Mysql是怎么样运行》集体读书笔记专栏补补课：

地址如下：从零开始学Mysql。

扩大

分区表

Innodb的分区表是指将一个表拆分为多个表然而留神这个概念和分库分表的物理分表有差异，在Innodb中尽管曾经在存储引擎进行了划分，实际上分区表在Server层上还是被当成一个表对待。

分区表的构建能够看上面的案例：

为了验证Sever层把它当做一个表对待这里能够进入命令行通过上面的命令查看，在截图中能够看到尽管外表上是一个表然而实际上Innodb存储引擎把它们拆分为四个表：

 InnoDB分区存在上面的几种形式：

范畴分区：通过数据的存储范畴进行划分分区。
哈希分区：通过哈希值进行分区。
List分区：针对字段取值的形式进行分区。

分区表有上面的特点：

升高Btree树层级，进步搜寻查问的效率。
第一次拜访须要拜访所有分区。
所有分区表独特应用一个MDL锁，这意味着对于分区表的锁表会同步解决
因为对于server层来说分区表只是一张表，所以分区实际上没有进步性能。

分库分表

分库分表依照严格来说应该分为分库和分表，分库的解决状况个别比拟少更多的是依据业务进行分表的操作，分表通常分为上面几种形式：

垂直分表：垂直分表指的是依据某表的数据依照某种规定冷热进行划分。

程度分表：程度分表通常依照数据行拆表，这种形式相似把实在的数据行拆分到多个表外面，避免单表数据过大，同时外部应用范畴值或者哈希值进行程度分表的数据查找，其中程度分表最为罕用。

留神本局部讲述的分表和下面的分区表是有区别的，在Server层这种分库分表会当作理论的拆分对待而不是同一个表。

而分库的概念当初应用的状况不是特地多了，在分库概念中分为上面的内容：

垂直分库：数据扩散在多个数据库或者分到多个节点。

程度分库：将数据表依照非凡业务规定划分，是每一个库负责各自的次要业务。同时数据库的根本构造配置雷同。程度分库通常还有一种场景是较为新的数据和较为老的数据放到不同的库中进行查看，同样和上面的结构图相似。

分库分表有哪些优缺点呢？

长处：

减少隔离性
减少并发和隔离性：因为数据结构在server层被看作不同的库和块，
和分区表尽管很像，然而实质上齐全不一样。

毛病：

对于局部生效的特色会成倍的减少和呈现。
单点事务不能够实现，须要引入分布式的锁进行管制。
垂直分库分表之后不可能join查问，会多写很多SQL。
对于范畴查问的SQL会存在问题

Dble和Mycat

简介：这两款中间件都是用于Mysql进行分库分表的市面上应用十分多的支流中间件，Mycat可能更为人熟知而Dble则是在Mycat的根底上更进一步优化和扩大。

根底运行原理：

剖析查问的SQL语句。
把SQL的查问依照中间件算法散发到多个库和多个表进行查问，同时发送到数据节点
将数据节点的数据进行汇集合并，最初返回给客户端。

Dble：高性能的Mysql分库分表中间件，由国内一家叫做爱可生的公司进行开发，能够说是国产之光，我的项目齐全开源同时基于另一个开源我的项目Mycat进行优化和改进，同时这款工具次要是由JAVA编写，对于一些理论应用的问题能够由大部分的开发人员尝试解决。

Dble的设计构造如下，对于客户端来说和平时连贯Mysql的分片没有区别然而实际上这是因为Dble外部做了一系列的优化操作：

Dble的根底概念：

Schema：虚构数据库（和传统数据库的Schema不同）。
ShardingTable：虚构表，通过虚构表把数据进行算法划分。
ShardingNode：虚构节点，存在数据库的Database中，能够认为一个DB就是一个节点。
dbGroup：理论的Mysql集群。
Database：示意理论的Database。

最初咱们通过一个简略的分表案例来看看Dble做了哪些操作：

Dble的分库分表特点是无论分库还是分表都是应用分表来实现的。

在下面的图中能够看到，首先咱们的物理表被Dble当作一个shariding table对待，这里的虚构表在Dble外部首先会被散发到两个Mysql节点，对于Mysql1和Mysql2来说他们之间是没有任何关系的单方不晓得对方存在的（和上一篇提到的主主架构是不一样的），而Dble则在这两个节点当中的理论db创立了虚拟机节点进行程度分库，外部通过算法散发到不同的库中进行查问，这里的表看起来很小是因为外部实际上有可能还存在其余的虚构节点，而对于Dble来说是拆分合并到不同的Mysql中治理，这些虚构节点对于Mysql1和Mysql来说是离开保存的数据，对于Mysql自身来说和一般的数据没有显著感知和区别，真正的数据合并则由Dble实现。

Dble装置搭建和应用

对于具体的操作应用能够参考官网所写的文档：Introduction · Dble manual (actiontech.github.io)，装置过程这里就略过了咱们重点从Dble的配置开始：

首先Dble有几个重要的配置文件：

cluster.cnf:集群参数配置
bootstrap.cnf:实例参数配置，包含JVM启动参数，Dble性能，定时工作，端口等
user.xml:Dble 用户配置
db.xml：数据库相干配置
sharding.xml：数据拆分相干配置

留神这些文件在装置好的Dble目录外面都是模板，除开局部须要依据本人的Mysql状况批改配置之外，只须要间接改名去掉_template即可。

接下来是批改db.xml文件，在这个文件中须要依据本人的数据库节点状况进行相干配置的批改，比方下方截图中的框线局部须要进行改变为本人的Mysql节点配置。

如果截图看不清也能够参考官网给的一个样板进行批改，须要改的中央都有相干的标识，比拟好了解。

<?xml version="1.0"?><Dble:db xmlns:Dble="http://Dble.cloud/">    <dbGroup name="dbGroup1" rwSplitMode="1" delayThreshold="100">        <heartbeat errorRetryCount="1" timeout="10">show slave status</heartbeat>        <dbInstance name="instanceM1" url="ip4:3306" user="your_user" password="your_psw" maxCon="200" minCon="50" primary="true">            <property name="testOnCreate">false</property>            <property name="testOnBorrow">false</property>            <property name="testOnReturn">false</property>            <property name="testWhileIdle">true</property>            <property name="connectionTimeout">30000</property>            <property name="connectionHeartbeatTimeout">20</property>            <property name="timeBetweenEvictionRunsMillis">30000</property>            <property name="idleTimeout">600000</property>            <property name="heartbeatPeriodMillis">10000</property>            <property name="evictorShutdownTimeoutMillis">10000</property>        </dbInstance>        <!-- can have multi read instances -->        <dbInstance name="instanceS1" url="ip5:3306" user="your_user" password="your_psw" maxCon="200" minCon="50" primary="false">            <property name="heartbeatPeriodMillis">60000</property>        </dbInstance>    </dbGroup></Dble:db>

接下来是批改user.xml局部，这部分须要留神有managerUser和shardingUser两个角色，一个是管理员负责管理Dble的用户，另一个sharingUser则须要建表权限对于客户端申请进行分库分表。

<?xml version="1.0" encoding="UTF-8"?><Dble:user xmlns:Dble="http://Dble.cloud/">    <managerUser name="man1" password="654321" whiteIPs="127.0.0.1,0:0:0:0:0:0:0:1" readOnly="false"/>    <managerUser name="user" usingDecrypt="true" readOnly="true" password="AqEkFEuIFAX6g2TJQnp4cJ2r7Yc0Z4/KBsZqKhT8qSz18Aj91e8lxO49BKQElC6OFfW4c38pCYa8QGFTub7pnw==" />    <shardingUser name="root" password="123456" schemas="testdb" readOnly="false" blacklist="blacklist1" maxCon="20"/>    <shardingUser name="root2" password="123456" schemas="testdb,testdb2" maxCon="20" tenant="tenant1">        <privileges check="true">            <schema name="testdb" dml="0110">                <table name="tb01" dml="0000"/>                <table name="tb02" dml="1111"/>            </schema>        </privileges>    </shardingUser>    <!--rwSplitUser not work for now-->    <rwSplitUser name="rwsu1" password="123456" dbGroup="dbGroup1" blacklist="blacklist1"                 maxCon="20"/>    <blacklist name="blacklist1">        <property name="selectAllow">true</property>    </blacklist></Dble:user>

最初咱们来看看Dble的外围配置sharing.xml，依据官网的介绍他有上面的三个局部的次要内容。

schema (虚构schema，可配置多个)
shardingNode (虚构分片，可配置多个)
function (拆分算法，可配置多个)

反对的分区算法：目前已反对的分区算法有: hash, stringhash, enum, numberrange, patternrange, date，jumpstringhash，具体的分区算法细节能够浏览文档相干内容介绍，这里就不过多介绍了。

目前国内应用的案例比拟少这里实战局部间接找了一篇博客，这里就不做演示Dble的分库分表了，有须要的时候再回来看看即可：

Dble分库分表实战_李如磊的技术博客_51CTO博客

如何进步分库分表性能？

进步分库分表性能问题首先想到的是搭建多个主备节点将主备复制和Dble进行联合。

其次能够在Dble上配置读写拆散，配置读写拆散同样能够参考官网文档。

分库分表存在问题

dble主动治理分库分表实际上也是存在上面的问题的，而dble是基于mycat进行解决的，上面的规定对于分库分表来说都会有相似的问题：

查问语句中须要尽可能的带有拆分字段：

dble 依据拆分字段判断数据节点的地位。
无奈判断数据节点只能遍历所有的节点。这一点会导致分库分表查问的负优化

插入的语句同样必须带有拆分的字段：

Dble 依据拆分的字段，判断数据在那个点。

拆分尽量应用等值条件：

范畴拆分字段会导致过多节点扫描。
应用IN语句缩减IN子句点值的数量。

缩小表搜寻遍历：

上面这些动作都会对于性能造成影响

不带拆分字段。
Distinct，group by，order by。

减小后果集：

数据交互会导致查问性能受到影响。
分布式系统导致节点大量的数据交互。

跨节点连表：

对于常常join的表须要依照固定的规定拆分。
应用拆分字段作为join条件。
尽量对于驱动表减少更多过滤条件。
尽量减少数据的分页。
简单语句拆分为简略语句。

下面的内容小结如下：

缩小数据交互。
数据增删改查须要减少拆分字段。
连贯键进行拆分解决。

切换

切换的外围是保业务还是保数据？

如何进行身份切换：

进行备库同步
配置主库复制从库。
复制是一种平级的关系，能够独立。

切换策略：

单纯从切换策略卡率咱们能够看到存在上面的两种形式：

牢靠优先策略：意味着seconds\_behind\_master参数不能过大不能落后库太大。须要把A库切换为只读的模式，这时候业务只能读取不新增数据，当seconds\_behind\_master=0的时候意味着两个库同步。此时A库进行，B库进行复制A，A库开始复制B库。这个牢靠阐明的是数据牢靠，然而不保障业务不受影响，因为最大的问题来自于停机。
可用性策略：勾销期待数据的统一过程，A库只读B库敞开只读，B库进行复制A库，A库开始复制B库，长处是零碎没有不可写工夫，毛病是切换的时候如果有没有及时重放的relay log容易导致数据不统一。

对于大多数一般业务执行尽量选用牢靠优先策略，然而如果对于业务高可用严格倡议可用性策略，比方日志流水同样须要可用性，对于一些数据要求强一致性的比拟低容许肯定数据失落的业务则能够思考应用可用性策略。

业务如何切换？

预留接口，告诉连贯到新的数据库地址。
微服务框架告诉业务，比方注册核心。
外部应用DNS，域名连贯，切换之后刷新DNS解决。
- K8S应用了这种形式实现解决。
keepalived 进行VIP漂移。通过检测解决优先级解决。
代理的形式切换：加一层代理负载平衡解决。
Dble的时候主备切换

主动主从切换

keepalived 如何主备切换？

keepalive是常常被应用的中间件，在主动主从切换中它负责了身份切换和VIP飘移的角色，VIP即Virtual IP Address，是实现HA（高可用）零碎的一种计划，高可用的目标是通过技术手段防止因为零碎呈现故障而导致进行对外服务，个别实现形式是部署备用服务器，在主服务器呈现故障时接管业务。 VIP用于向客户端提供一个固定的“虚构”拜访地址，以防止后端服务器产生切换时对客户端的影响。

Keepalived的设计目标即是为了治理VIP，因而应用Keepalived实现VIP的配置非常简单。Keepalived采纳了Virtual Router Redundancy Protocol (VRRP)协定来进行实现主备服务器之间的通信以及选举。

keepalive的主从切换相似上面的对形式，当比方当MysqlA服务宕机会主动切换到下一个A`的服务器提供服务，外部通过肯定的选举算法选举出新节点。

Mha（master high availability） 如何进行主备切换？

Mha也是罕用的Mysql高可用组件，它通过自研主从切换的概念实现主备切换，这个组件由facebook工程师进行开发，同时反对GTID的形式，最大特点：在宕机的时候第一工夫登陆宕机服务器下载binlog日志。然而Mha最大的问题是无奈进行VIP漂移。

依据上面的图能够看到，在Mha的工作机制当中，如果发现A节点的服务宕机此时会立即登陆到A节点的服务器把文件进行抢救，然而这里存在复制的数据同步问题，在半同步复制中会有脱扣工夫导致binlog传送转变为异步传送有可能会呈现binlog没有传递过去的状况，这种状况下有可能会导致其余数据的不残缺导致数据不同步。

值得一提的是Mha的并不是间接通过客户端拜访宕机节点而是须要期待SLAVE节点的数据落库之后再通过从库拜访主库抢救binlog，这些操作根本都是来自于设计者日常工作教训中发现的一些问题针对的非凡解决所以非常受到宽广开发者的青眼。

当抢救binlog工作实现之后，Mha 的下一步是从新选去Master，留神宕机的节点不会用脚本尝试重启复原，因为这种状况下不通过人为干涉通常曾经没有太大的成果了，即便重启也有可能会有数据不统一的问题。

三高零碎搭建

在搭建三高之前，咱们须要思考为什么有时候集群搭建起来了为什么还会挂？起因是任何一个成熟的繁多零碎都不会单纯依赖某一个开源组件而是在中间层退出大量的容错机制避免某一组件崩盘造成大面积的损失，这里波及到DRDS的概念，DRDS示意（Distributed Relational Database Service）分布式的Mysql集群，而Mysql的集群通常不会是自身的集群，而是通过一系列的中间件维持三高的基本特征。

接下来咱们一步步来看下三高零碎是如何搭建的：

分库分表有一个问题点：咱们发现当dble呈现问题的时候会导致整个服务不可用，Dble的单点问题这里咱们后续进探讨，这里呈现了Mha和Dble联动来解决Mysql节点宕机的问题。

对于开发人员来说日常实际过程根本碰不到这个货色这里同样找了一篇在须要的时候进行学习大抵的搭建流程和一些根本配置即可：
爱可生DBLE Mha-dble高可用联动实例

上面是Mha联合DBLE对于整个架构的加强结构图：

通过Mha和dble的搭配，当节点呈现宕机的时候能够通过Mha进行节点的切换保障分库分表的失常工作。

然而咱们还发现一个问题那就是dble自身也是单点的，所以dble也须要做集群的负载平衡避免整个节点不可用，而对于dble的负载散发能够通过Haproxy联合zookeeper进行解决。

HAProxy 是一款提供高可用性、负载平衡以及基于TCP（第四层）和HTTP（第七层）利用的代理软件，反对虚拟主机，它是收费、疾速并且牢靠的一种解决方案。 HAProxy特地实用于那些负载特大的web站点，这些站点通常又须要会话放弃或七层解决。HAProxy运行在时下的硬件上，齐全能够反对数以万计的并发连贯。并且它的运行模式使得它能够很简略平安的整合进您以后的架构中，同时能够爱护你的web服务器不被裸露到网络上。
ZooKeeper是一个集中式服务，用于保护配置信息、命名、提供分布式同步和提供组服务。所有这些类型的服务都以某种模式被分布式应用应用。每次实现这些服务时，都有大量的工作用于修复不可避免的谬误和竞争条件。因为实现这类服务的难度，应用程序最后通常会疏忽它们，这使得它们在变动的状况下变得很软弱而且难以治理。即便做得正确这些服务的不同实现也会导致应用程序部署时的治理复杂性。

最初客户端通过keepalive的VIP飘移寻找网关的入口，通过选举散发之后找到对应的dble，dble再进行分库分表查找相干的数据进行解决，最初找到相干的Mysql节点汇总数据之后返回给客户端，当Mysql节点呈现问题的时候，Mha则会通过一系列的脚本抢救binlog文件之后从新选举主从节点。

至此一个三高架构的分布式Mysql集群的残缺构造实现，咱们把下面的文字用结构图示意能够看到还是十分复杂的：

总结

本局部内容讲述了Mysql分区表个性，以及一个国产开源的分库分表插件，其实分库分表对于大部分的中小我的项目根本都是不须要的，它通常呈现在比拟大的零碎架构当中，dble作为一款国产开源组件有着不错的体现，在Mycat的根底上改良的同时应用JAVA语言编写非常贴合WEB开发人员的爱好。

在切换的局部咱们讲述了另外两个组件：MHA和Keepalive，这两个组件由大量的资源和案例参考，所以这里简略拿来介绍它们是如何和Mysql进行组合加强集群架构的高可用个性的，

写到最初

三高架构看起来十分复杂并且高大上，然而实际上咱们把组件拆分实现之后发现各个组件的角色分工十分明确，作用也比拟显著。当然这些内容可能更多是运维会接触到和应用到，对于开发人员来说这些内容只须要简略理解流程和实践即可。