引言

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

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

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

扩大

分区表

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

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

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

​

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

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

​

分区表有上面的特点：

1. 升高 Btree 树层级，进步搜寻查问的效率。
2. 第一次拜访须要拜访所有分区。
3. 所有分区表独特应用一个 MDL 锁，这意味着对于分区表的锁表会同步解决
4. 因为对于 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 进行组合加强集群架构的高可用个性的，

写到最初

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