引言
内容为慕课网的《高并发 高性能 高可用 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进行结合。
其次可以在Dble上配置读写分离，配置读写分离同样可以参考官方文档。
分库分表存在问题
dble自动管理分库分表实际上也是存在下面的问题的，而dble是基于mycat进行处理的，下面的规则对于分库分表来说都会有类似的问题：
查询语句中需要尽可能的带有拆分字段：
- dble 根据拆分字段判断数据节点的位置。
- 无法判断数据节点只能遍历所有的节点。这一点会导致分库分表查询的负优化
插入的语句同样必须带有拆分的字段：
- Dble 根据拆分的字段，判断数据在那个点 。
拆分尽量使用等值条件：
- 范围拆分字段会导致过多节点扫描。
- 使用IN语句缩减IN子句点值的数量。
减少表搜索遍历：
下面这些动作都会对于性能造成影响
- 不带拆分字段。
- Distinct，group by，order by。
减小结果集：
- 数据交互会导致查询性能受到影响。
- 分布式系统导致节点大量的数据交互。
跨节点连表：
- 对于经常join的表需要按照固定的规则拆分。
- 使用拆分字段作为join条件。
- 尽量对于驱动表增加更多过滤条件。
- 尽量减少数据的分页。
- 复杂语句拆分为简单语句。
上面的内容小结如下：
- 减少数据交互。
- 数据增删改查需要增加拆分字段。
- 连接键进行拆分处理。
