一、Mycat开源宣言
2013 年阿里的 Cobar 在社区使用过程中发现存在一些比较严重的问题，及其使用限制。Mycat 是基于开源 Cobar 演变而来，我们对 cobar 的代码进行了彻底的重构，使用 NIO 重构了网络模块，并且优化了 Buffer 内核，增强了聚合，Join 等基本特性，同时兼容绝大多数数据库成为通用的数据库中间件。1.4 版本以后 完全的脱离基本 cobar 内核，结合 Mycat 集群管理、自动扩容、智能优化，成为高性能的中间件。
二、数据库切分概述
2.1 OLTP和OLAP
在互联网时代，海量数据的存储与访问成为系统设计与使用的瓶颈问题，对于海量数据处理，按照使用场景，
主要分为两种类型：联机事务处理（OLTP）和联机分析处理（OLAP）。
联机事务处理（OLTP）也称为面向交易的处理系统，其基本特征是原始数据可以立即传送到计算中心进行处
理，并在很短的时间内给出处理结果。
联机分析处理（OLAP）是指通过多维的方式对数据进行分析、查询和报表，可以同数据挖掘工具、统计分析
工具配合使用，增强决策分析功能。
对于两者的主要区别可以用下表来说明：
2.2 关系型数据库和 NoSQL 数据库
针对上面两类系统有多种技术实现方案，存储部分的数据库主要分为两大类：关系型数据库与 NoSQL 数据
库。
关系型数据库，是建立在关系模型基础上的数据库，其借助于集合代数等数学概念和方法来处理数据库中的
数据。主流的 oracle、DB2、MS SQL Server 和 mysql 都属于这类传统数据库。
NoSQL 数据库，全称为 Not Only SQL，意思就是适用关系型数据库的时候就使用关系型数据库，不适用的
时候也没有必要非使用关系型数据库不可，可以考虑使用更加合适的数据存储。主要分为临时性键值存储
（memcached、Redis）、永久性键值存储（ROMA、Redis）、面向文档的数据库（MongoDB、CouchDB）、面向列的数据库（Cassandra、HBase），每种 NoSQL 都有其特有的使用场景及优点。
Oracle，mysql 等传统的关系数据库非常成熟并且已大规模商用，为什么还要用 NoSQL 数据库呢？主要是
由于随着互联网发展，数据量越来越大，对性能要求越来越高，传统数据库存在着先天性的缺陷，即单机（单库）性能瓶颈，并且扩展困难。这样既有单机单库瓶颈，却又扩展困难，自然无法满足日益增长的海量数据存储及其性能要求，所以才会出现了各种不同的 NoSQL 产品，NoSQL 根本性的优势在于在云计算时代，简单、易于大规模分布式扩展，并且读写性能非常高。
下面分析下两者的特点，及优缺点：
虽然在云计算时代，传统数据库存在着先天性的弊端，但是 NoSQL 数据库又无法将其替代，NoSQL 只能作
为传统数据的补充而不能将其替代，所以规避传统数据库的缺点是目前大数据时代必须要解决的问题。如果传统数据易于扩展，可切分，就可以避免单机（单库）的性能缺陷，但是由于目前开源或者商用的传统数据库基本不支持大规模自动扩展，所以就需要借助第三方来做处理。
2.3 何为数据切分？
简单来说，就是指通过某种特定的条件，将我们存放在同一个数据库中的数据分散存放到多个数据库（主机）上面，以达到分散单台设备负载的效果。
数据的切分（Sharding）根据其切分规则的类型，可以分为两种切分模式。一种是按照不同的表（或者
Schema）来切分到不同的数据库（主机）之上，这种切可以称之为数据的垂直（纵向）切分；另外一种则是根据表中的数据的逻辑关系，将同一个表中的数据按照某种条件拆分到多台数据库（主机）上面，这种切分称之为数据的水平（横向）切分。
垂直切分的最大特点就是规则简单，实施也更为方便，尤其适合各业务之间的耦合度非常低，相互影响很小，业务逻辑非常清晰的系统。在这种系统中，可以很容易做到将不同业务模块所使用的表分拆到不同的数据库中。根据不同的表来进行拆分，对应用程序的影响也更小，拆分规则也会比较简单清晰。
水平切分于垂直切分相比，相对来说稍微复杂一些。因为要将同一个表中的不同数据拆分到不同的数据库中，对于应用程序来说，拆分规则本身就较根据表名来拆分更为复杂，后期的数据维护也会更为复杂一些。
2.4 垂直切分
一个数据库由很多表的构成，每个表对应着不同的业务，垂直切分是指按照业务将表进行分类，分布到不同
的数据库上面，这样也就将数据或者说压力分担到不同的库上面，如下图：
往往系统之有些表难以做到完全的独立，存在各扩库 join 的情况，对于这类的表，就需要去做平衡，
是数据库让步业务，共用一个数据源，还是分成多个库，业务之间通过接口来做调用。在系统初期，数据量比较少，或者资源有限的情况下，会选择共用数据源，但是当数据发展到了一定的规模，负载很大的情况，就需要必须去做分割。
由于垂直切分是按照业务的分类将表分散到不同的库，所以有些业务表会过于庞大，存在单库读写与存储瓶
颈，所以就需要水平拆分来做解决。
2.5 水平切分
相对于垂直拆分，水平拆分不是将表做分类，而是按照某个字段的某种规则来分散到多个库之中，每个表中
包含一部分数据。简单来说，我们可以将数据的水平切分理解为是按照数据行的切分，就是将表中的某些行切分到一个数据库，而另外的某些行又切分到其他的数据库中，如图：
拆分数据就需要定义分片规则。关系型数据库是行列的二维模型，拆分的第一原则是找到拆分维度。比如：
从会员的角度来分析，商户订单交易类系统中查询会员某天某月某个订单，那么就需要按照会员结合日期来拆分，不同的数据按照会员 ID 做分组，这样所有的数据查询 join 都会在单库内解决；如果从商户的角度来讲，要查询某个商家某天所有的订单数，就需要按照商户 ID 做拆分；但是如果系统既想按会员拆分，又想按商家数据，则会有一定的困难。如何找到合适的分片规则需要综合考虑衡量。
几种典型的分片规则包括：
- 按照用户 ID 求模，将数据分散到不同的数据库，具有相同数据用户的数据都被分散到一个库中；
- 按照日期，将不同月甚至日的数据分散到不同的库中；
- 按照某个特定的字段求摸，或者根据特定范围段分散到不同的库中。
三、Mycat 概述
3.1 功能介绍
Mycat 是什么？从定义和分类来看，它是一个开源的分布式数据库系统，是一个实现了 MySQL 协议的Server，前端用户可以把它看作是一个数据库代理，用 MySQL 客户端工具和命令行访问，而其后端可以用MySQL 原生（Native）协议与多个 MySQL 服务器通信，也可以用 JDBC 协议与大多数主流数据库服务器通信，其核心功能是分表分库。
对于 DBA 来说，可以这么理解 Mycat：
Mycat 就是 MySQL Server，而 Mycat 后面连接的 MySQL Server就好象是 MySQL 的存储引擎,如InnoDB，MyISAM 等，因此，Mycat 本身并不存储数据，数据是在后端的 MySQL 上存储的，因此数据可靠性以及事务等都是 MySQL 保证的，简单的说，Mycat 就是MySQL 最佳伴侣，它在一定程度上让 MySQL 拥有了能跟 Oracle PK 的能力。
对于软件工程师来说，可以这么理解 Mycat：
Mycat 就是一个近似等于 MySQL 的数据库服务器，你可以用连接 MySQL 的方式去连接 Mycat（除了端口不同，默认的 Mycat 端口是 8066 而非 MySQL 的 3306，因此需要在连接字符串上增加端口信息），大多数情况下，可以用你熟悉的对象映射框架使用 Mycat，但建议对于分片表，尽量使用基础的 SQL 语句，因为这样能达到最佳性能，特别是几千万甚至几百亿条记录的情况下。
对于架构师来说，可以这么理解 Mycat：
Mycat 是一个强大的数据库中间件，不仅仅可以用作读写分离、以及分表分库、容灾备份，而且可以用于多租户应用开发、云平台基础设施、让你的架构具备很强的适应性和灵活性，借助于即将发布Mycat 智能优化模块，系统的数据访问瓶颈和热点一目了然，根据这些统计分析数据，你可以自动或手工调整后端存储，将不同的表映射到不同存储引擎上，而整个应用的代码一行也不用改变。
3.2 Mycat 原理
Mycat 的原理中最重要的一个动词是“拦截”，它拦截了用户发送过来的 SQL 语句，首先对 SQL 语句做了一些特定的分析：如分片分析、路由分析、读写分离分析、缓存分析等，然后将此 SQL 发往后端的真实数据库，并将返回的结果做适当的处理，最终再返回给用户。
当 Mycat 收到一个 SQL 时，会先解析这个 SQL，查找涉及到的表，然后看此表的定义，如果有分片规则，则获取到 SQL 里分片字段的值，并匹配分片函数，得到该 SQL 对应的分片列表，然后将 SQL 发往这些分片去执行，最后收集和处理所有分片返回的结果数据，并输出到客户端。以 select * from Orders where prov=?语句为例，查到 prov=wuhan，按照分片函数，wuhan 返回 dn1，于是 SQL 就发给了 MySQL1，去取 DB1 上的查询结果，并返回给用户。
如果上述 SQL 改为 select * from Orders where prov in (‘wuhan’,‘beijing’)，那么，SQL 就会发给MySQL1 与 MySQL2 去执行，然后结果集合并后输出给用户。但通常业务中我们的 SQL 会有 Order By 以及Limit 翻页语法，此时就涉及到结果集在 Mycat 端的二次处理，这部分的代码也比较复杂，而最复杂的则属两个表的 Jion 问题，为此，Mycat 提出了创新性的 ER 分片、全局表、HBT（Human Brain Tech)人工智能的 Catlet、以及结合 Storm/Spark 引擎等十八般武艺的解决办法，从而成为目前业界最强大的方案，这就是开源的力量。
3.3 应用场景
Mycat 发展到现在，适用的场景已经很丰富，而且不断有新用户给出新的创新性的方案，以下是几个典型的应用场景：
- 1.单纯的读写分离，此时配置最为简单，支持读写分离，主从切换；
- 2.分表分库，对于超过 1000 万的表进行分片，最大支持 1000 亿的单表分片；
- 3.多租户应用，每个应用一个库，但应用程序只连接 Mycat，从而不改造程序本身，实现多租户化；
- 4.报表系统，借助于 Mycat 的分表能力，处理大规模报表的统计；
- 5.替代 Hbase，分析大数据；
- 6.作为海量数据实时查询的一种简单有效方案，比如 100 亿条频繁查询的记录需要在 3 秒内查询出来结果，除了基于主键的查询，还可能存在范围查询或其他属性查询，此时 Mycat 可能是最简单有效的选择。
四、Mycat 中的概念
4.1 数据库中间件
前面讲了 Mycat 是一个开源的分布式数据库系统，但是由于真正的数据库需要存储引擎，而 Mycat 并没有
存储引擎，所以并不是完全意义的分布式数据库系统。
那么 Mycat 是什么？Mycat 是数据库中间件，就是介于数据库与应用之间，进行数据处理与交互的中间服务。由于前面讲的对数据进行分片处理之后，从原有的一个库，被切分为多个分片数据库，所有的分片数据库集群构成了整个完整的数据库存储。
如上图所表示，数据被分到多个分片数据库后，应用如果需要读取数据，就要需要处理多个数据源的数据。如果没有数据库中间件，那么应用将直接面对分片集群，数据源切换、事务处理、数据聚合都需要应用直接处理，原本该是专注于业务的应用，将会花大量的工作来处理分片后的问题，最重要的是每个应用处理将是完全的重复造轮子。所以有了数据库中间件，应用只需要集中与业务处理，大量的通用的数据聚合，事务，数据源切换都由中间件来处理，中间件的性能与处理能力将直接决定应用的读写性能，所以一款好的数据库中间件至关重要。
4.2 逻辑库(schema)
通常对实际应用来说，并不需要知道中间件的存在，业务开发人员只需要知道数据库的概念，所以数据库中间件可以被看做是一个或多个数据库集群构成的逻辑库。在云计算时代，数据库中间件可以以多租户的形式给一个或多个应用提供服务，每个应用访问的可能是一个独立或者是共享的物理库，常见的如阿里云数据库服务器 RDS。
4.3 逻辑表（table）
4.3.1 逻辑表
既然有逻辑库，那么就会有逻辑表，分布式数据库中，对应用来说，读写数据的表就是逻辑表。逻辑表，可
以是数据切分后，分布在一个或多个分片库中，也可以不做数据切分，不分片，只有一个表构成。
4.3.2 分片表
分片表，是指那些原有的很大数据的表，需要切分到多个数据库的表，这样，每个分片都有一部分数据，所
有分片构成了完整的数据。例如在 mycat 配置中的 t_node 就属于分片表，数据按照规则被分到 dn1,dn2 两个分片节点(dataNode)上。
4.3.3 非分片表
一个数据库中并不是所有的表都很大，某些表是可以不用进行切分的，非分片是相对分片表来说的，就是那
些不需要进行数据切分的表。如下配置中 t_node，只存在于分片节点（dataNode）dn1 上。
4.3.4 ER 表
关系型数据库是基于实体关系模型（Entity-Relationship Model)之上，通过其描述了真实世界中事物与关系，Mycat 中的 ER 表即是来源于此。根据这一思路，提出了基于 E-R 关系的数据分片策略，子表的记录与所关联的父表记录存放在同一个数据分片上，即子表依赖于父表，通过表分组（Table Group）保证数据 Join 不会跨库操作。表分组（Table Group）是解决跨分片数据 join 的一种很好的思路，也是数据切分规划的重要一条规则。
4.3.5 全局表
一个真实的业务系统中，往往存在大量的类似字典表的表，这些表基本上很少变动，字典表具有以下几个特
性：
- 变动不频繁；
- 数据量总体变化不大；
- 数据规模不大，很少有超过数十万条记录。
对于这类的表，在分片的情况下，当业务表因为规模而进行分片以后，业务表与这些附属的字典表之间的关联，就成了比较棘手的问题，所以 Mycat 中通过数据冗余来解决这类表的 join，即所有的分片都有一份数据的拷贝，所有将字典表或者符合字典表特性的一些表定义为全局表。数据冗余是解决跨分片数据 join 的一种很好的思路，也是数据切分规划的另外一条重要规则。
4.4 分片节点(dataNode)
数据切分后，一个大表被分到不同的分片数据库上面，每个表分片所在的数据库就是分片节点（dataNode）。
4.5 节点主机(dataHost)
数据切分后，每个分片节点（dataNode）不一定都会独占一台机器，同一机器上面可以有多个分片数据库，这样一个或多个分片节点（dataNode）所在的机器就是节点主机（dataHost）,为了规避单节点主机并发数限制，尽量将读写压力高的分片节点（dataNode）均衡的放在不同的节点主机（dataHost）。
4.6 分片规则(rule)
前面讲了数据切分，一个大表被分成若干个分片表，就需要一定的规则，这样按照某种业务规则把数据分到某个分片的规则就是分片规则，数据切分选择合适的分片规则非常重要，将极大的避免后续数据处理的难度。
4.7 全局序列号(sequence)
数据切分后，原有的关系数据库中的主键约束在分布式条件下将无法使用，因此需要引入外部机制保证数据唯一性标识，这种保证全局性的数据唯一标识的机制就是全局序列号（sequence）。
4.8 多租户
多租户技术或称多重租赁技术，是一种软件架构技术，它是在探讨与实现如何于多用户的环境下共用相同的系统或程序组件，并且仍可确保各用户间数据的隔离性。在云计算时代，多租户技术在共用的数据中心以单一系统架构与服务提供多数客户端相同甚至可定制化的服务，并且仍然可以保障客户的数据隔离。目前各种各样的云计算服务就是这类技术范畴，例如阿里云数据库服务（RDS）、阿里云服务器等等。多租户在数据存储上存在三种主要的方案，分别是：
4.8.1 独立数据库
这是第一种方案，即一个租户一个数据库，这种方案的用户数据隔离级别最高，安全性最好，但成本也高。
优点：
为不同的租户提供独立的数据库，有助于简化数据模型的扩展设计，满足不同租户的独特需求；
如果出现故障，恢复数据比较简单。
缺点：
增大了数据库的安装数量，随之带来维护成本和购置成本的增加。
这种方案与传统的一个客户、一套数据、一套部署类似，差别只在于软件统一部署在运营商那里。如果面对的是银行、医院等需要非常高数据隔离级别的租户，可以选择这种模式，提高租用的定价。如果定价较低，产品走低价路线，这种方案一般对运营商来说是无法承受的。
4.8.2 共享数据库，隔离数据架构
这是第二种方案，即多个或所有租户共享 Database，但是每个租户一个 Schema。
优点：
为安全性要求较高的租户提供了一定程度的逻辑数据隔离，并不是完全隔离；每个数据库可以支持更多的租户数量。
缺点：
如果出现故障，数据恢复比较困难，因为恢复数据库将牵扯到其他租户的数据；
如果需要跨租户统计数据，存在一定困难。
4.8.3 共享数据库，共享数据架构
这是第三种方案，即租户共享同一个 Database、同一个 Schema，但在表中通过 TenantID 区分租户的数据。这是共享程度最高、隔离级别最低的模式。
优点：
三种方案比较，第三种方案的维护和购置成本最低，允许每个数据库支持的租户数量最多。
缺点：
隔离级别最低，安全性最低，需要在设计开发时加大对安全的开发量；
数据备份和恢复最困难，需要逐表逐条备份和还原；
如果希望以最少的服务器为最多的租户提供服务，并且租户接受以牺牲隔离级别换取降低成本，这种方案最适合。
五、Mycat 的分片 join
Join 绝对是关系型数据库中最常用一个特性，然而在分布式环境中,跨分片的 join 确是最复杂的，最难解决一
个问题。
Mycat 目前版本支持跨分片的 join,主要实现的方式有四种：
1、全局表
2、ER 分片
3、catletT(人工智能)
4、ShareJoin
ShareJoin 在开发版中支持，前面三种方式 1.3.0.1 支持。
5.1 全局表
一个真实的业务系统中，往往存在大量的类似字典表的表格，它们与业务表之间可能有关系，这种关系，可以理解为“标签”，而不应理解为通常的“主从关系”，这些表基本上很少变动，可以根据主键 ID 进行缓存。
在分片的情况下，当业务表因为规模而进行分片以后，业务表与这些附属的字典表之间的关联，就成了比较棘手的问题，考虑到字典表具有以下几个特性：
1、变动不频繁
2、数据量总体变化不大
3、数据规模不大，很少有超过数十万条记录。
鉴于此，MyCAT 定义了一种特殊的表，称之为“全局表”，全局表具有以下特性：
1、全局表的插入、更新操作会实时在所有节点上执行，保持各个分片的数据一致性
2、全局表的查询操作，只从一个节点获取
3、全局表可以跟任何一个表进行 JOIN 操作
将字典表或者符合字典表特性的一些表定义为全局表，则从另外一个方面，很好的解决了数据 JOIN 的难题。通过全局表+基于 E-R 关系的分片策略，MyCAT 可以满足 80%以上的企业应用开发。
全局表配置比较简单，不用写 Rule 规则，如下配置即可：
需要注意的是，全局表每个分片节点上都要有运行创建表的 DDL 语句。
5.2 ER Join
MyCAT 借鉴了 NewSQL 领域的新秀 Foundation DB 的设计思路，Foundation DB 创新性的提出了 Table Group 的概念，其将子表的存储位置依赖于主表，并且物理上紧邻存放，因此彻底解决了 JION 的效率和性能问题，根据这一思路，提出了基于 E-R 关系的数据分片策略，子表的记录与所关联的父表记录存放在同一个数据分片上。
customer 采用 sharding-by-intfile 这个分片策略，分片在 dn1,dn2 上，orders 依赖父表进行分片，两个表的关联关系为 orders.customer_id=customer.id。于是数据分片和存储的示意图如下：
这样一来，分片 Dn1 上的的 customer 与 Dn1 上的 orders 就可以进行局部的 JOIN 联合，Dn2 上也如此，再合并两个节点的数据即可完成整体的 JOIN，试想一下，每个分片上 orders 表有 100 万条，则 10 个分片就有 1 个亿，基于 E-R 映射的数据分片模式，基本上解决了 80%以上的企业应用所面临的问题。
以上述例子为例，schema.xml 中定义如下的分片配置：
5.3 Share join
ShareJoin 是一个简单的跨分片 Join,基于 HBT 的方式实现。目前支持 2 个表的 join,原理就是解析 SQL 语句，拆分成单表的 SQL 语句执行，然后把各个节点的数据汇集。
5.4 catlet（人工智能）
解决跨分片的 SQL JOIN 的问题，远比想象的复杂，而且往往无法实现高效的处理，既然如此，就依靠人工的智力，去编程解决业务系统中特定几个必须跨分片的 SQL 的 JOIN 逻辑，MyCAT 提供特定的 API 供程序员调用，这就是 MyCAT 创新性的思路——人工智能。
六、全局序列号
6.1 全局序列号介绍
在实现分库分表的情况下，数据库自增主键已无法保证自增主键的全局唯一。为此，MyCat 提供了全局sequence，并且提供了包含本地配置和数据库配置等多种实现方式。
6.2 本地文件方式
1、原理：此方式 MyCAT 将 sequence 配置到文件中，当使用到 sequence 中的配置后，MyCAT 会更下classpath 中的 sequence_conf.properties 文件中 sequence 当前的值。
2、配置方式：
在 sequence_conf.properties 文件中做如下配置：
GLOBAL_SEQ.HISIDS=
GLOBAL_SEQ.MINID=1001
GLOBAL_SEQ.MAXID=1000000000
GLOBAL_SEQ.CURID=1000
其中 HISIDS 表示使用过的历史分段(一般无特殊需要可不配置)，MINID 表示最小 ID 值，MAXID 表示最大ID 值，CURID 表示当前 ID 值。
3、server.xml 中配置：
注：sequnceHandlerType 需要配置为 0，表示使用本地文件方式。
4、使用示例：
insert into table1(id,name) values( 1700760658708140032,‘test’);
缺点：当 MyCAT 重新发布后，配置文件中的 sequence 会恢复到初始值。
优点：本地加载，读取速度较快。
6.3 数据库方式
原理：在数据库中建立一张表，存放 sequence 名称(name)，sequence 当前值(current_value)，步长(increment int 类型每次读取多少个 sequence，假设为 K)等信息。
6.4 本地时间戳方式
ID= 64 位二进制 (42(毫秒)+5(机器 ID)+5(业务编码)+12(重复累加)
换算成十进制为 18 位数的 long 类型，每毫秒可以并发 12 位二进制的累加。
6.5 分布式 ZK ID 生成器
Zk 的连接信息统一在 myid.properties 的 zkURL 属性中配置。
基于 ZK 与本地配置的分布式 ID 生成器(可以通过 ZK 获取集群（机房）唯一 InstanceID，也可以通过配置文
件配置 InstanceID)
ID 结构：long 64 位，ID 最大可占 63 位
6.6 ZK 递增方式
Zk 的连接信息统一在 myid.properties 的 zkURL 属性中配置。
4 是 zookeeper 实现递增序列号
- 配置文件：sequence_conf.properties
- 只要配置好 ZK 地址和表名的如下属性
- TABLE.MINID 某线程当前区间内最小值
- TABLE.MAXID 某线程当前区间内最大值
- TABLE.CURID 某线程当前区间内当前值
- 文件配置的 MAXID 以及 MINID 决定每次取得区间，这个对于每个线程或者进程都有效
- 文件中的这三个属性配置只对第一个进程的第一个线程有效，其他线程和进程会动态读取 ZK
七、Mycat 分片规则
7.1 分片规则概述
在数据切分处理中，特别是水平切分中，中间件最终要的两个处理过程就是数据的切分、数据的聚合。选择
合适的切分规则，至关重要，因为它决定了后续数据聚合的难易程度，甚至可以避免跨库的数据聚合处理。
7.2 Mycat 全局表
如果你的业务中有些数据类似于数据字典，比如配置文件的配置，常用业务的配置或者数据量不大很少变动的表，这些表往往不是特别大，而且大部分的业务场景都会用到，那么这种表适合于 Mycat 全局表，无须对数据进行切分，只要在所有的分片上保存一份数据即可，Mycat 在 Join 操作中，业务表与全局表进行 Join 聚合会优先选择相同分片内的全局表 join，避免跨库 Join，在进行数据插入操作时，mycat 将把数据分发到全局表对应的所有分片执行，在进行数据读取时候将会随机获取一个节点读取数据。
目前 Mycat 没有做全局表的数据一致性检查，后续版本 1.4 之后可能会提供全局表一致性检查，检查每个分
片的数据一致性。
全局表的配置如下
7.3 ER 分片表
有一类业务，例如订单（order）跟订单明细（order_detail）,明细表会依赖于订单，也就是说会存在表的主从关系，这类似业务的切分可以抽象出合适的切分规则，比如根据用户 ID 切分,其他相关的表都依赖于用户 ID，再或者根据订单 ID 切分，总之部分业务总会可以抽象出父子关系的表。这类表适用于 ER 分片表，子表的记录与所关联的父表记录存放在同一个数据分片上，避免数据 Join 跨库操作。
以 order 与 order_detail 例子为例，schema.xml 中定义如下的分片配置,order,order_detail 根据 order_id进行数据切分，保证相同 order_id 的数据分到同一个分片上，在进行数据插入操作时，Mycat 会获取 order 所在的分片，然后将 order_detail 也插入到 order 所在的分片。
7.4 多对多关联
有一类业务场景是 “主表 A+关系表+主表 B”，举例来说就是商户会员+订单+商户，对应这类业务，如何切分？
从会员的角度，如果需要查询会员购买的订单，那按照会员进行切分即可，但是如果要查询商户当天售出的订单，那又需要按照商户做切分，可是如果既要按照会员又要按照商户切分，几乎是无法实现，这类业务如何选择切分规则非常难。目前还暂时无法很好支持这种模式下的 3 个表之间的关联。目前总的原则是需要从业务角度来看，关系表更偏向哪个表，即“A 的关系”还是“B 的关系”，来决定关系表跟从那个方向存储，未来 Mycat版本中将考虑将中间表进行双向复制，以实现从 A-关系表 以及 B-关系表的双向关联查询如下图所示：
7.5 Mycat 常用的分片规则
7.5.1 分片枚举
通过在配置文件中配置可能的枚举 id，自己配置分片，本规则适用于特定的场景，比如有些业务需要按照省份或区县来做保存，而全国省份区县固定的，这类业务使用本条规则。
7.5.2 固定分片 hash 算法
本条规则类似于十进制的求模运算，区别在于是二进制的操作,是取 id 的二进制低 10 位，即 id 二进制&1111111111。此算法的优点在于如果按照 10 进制取模运算，在连续插入 1-10 时候 1-10 会被分到 1-10 个分片，增大了插入的事务控制难度，而此算法根据二进制则可能会分到连续的分片，减少插入事务事务控制难度。
7.5.3 范围约定
此分片适用于，提前规划好分片字段某个范围属于哪个分片，
start <= range <= end.
range start-end ,data node index
K=1000,M=10000.
7.5.4 取 模
此规则为对分片字段求摸运算。
7.5.5 按日期（天）分片
此规则为按天分片。
7.5.6 取模范围约束
此种规则是取模运算与范围约束的结合，主要为了后续数据迁移做准备，即可以自主决定取模后数据的节点
分布。
7.5.7 截取数字做 hash 求模范围约束
此种规则类似于取模范围约束，此规则支持数据符号字母取模。
7.5.8 应用指定
此规则是在运行阶段有应用自主决定路由到那个分片。
7.5.9 截取数字 hash 解析
此规则是截取字符串中的 int 数值 hash 分片。
7.5.10 一致性 hash
一致性 hash 预算有效解决了分布式数据的扩容问题。
7.5.11 按单月小时拆分
此规则是单月内按照小时拆分，最小粒度是小时，可以一天最多 24 个分片，最少 1 个分片，一个月完后下月
从头开始循环。每个月月尾，需要手工清理数据。
7.5.12 范围求模分片
先进行范围分片计算出分片组，组内再求模，优点可以避免扩容时的数据迁移，又可以一定程度上避免范围分片的热点问题，综合了范围分片和求模分片的优点，分片组内使用求模可以保证组内数据比较均匀，分片组之间是范围分片可以兼顾范围查询。最好事先规划好分片的数量，数据扩容时按分片组扩容，则原有分片组的数据不需要迁移。由于分片组内数据比较均匀，所以分片组内可以避免热点数据问题。
7.5.13 日期范围 hash 分片
思想与范围求模一致，当由于日期在取模会有数据集中问题，所以改成 hash 方法。先根据日期分组，再根据时间 hash 使得短期内数据分布的更均匀优点可以避免扩容时的数据迁移，又可以一定程度上避免范围分片的热点问题要求日期格式尽量精确些，不然达不到局部均匀的目的。
7.5.14 冷热数据分片
根据日期查询日志数据 冷热数据分布 ，最近 n 个月的到实时交易库查询，超过 n 个月的按照 m 天分片。
7.5.15 自然月分片
按月份列分区 ，每个自然月一个分片，格式 between 操作解析的范例。
7.5.16 有状态分片算法
有状态分片算法与之前的分片算法不同,它是为数据自动迁移而设计的。直至 2018 年 7 月 24 日为止,现支持有状态算法的分片策略只有 crc32slot 欢迎大家提供更多有状态分片算法。
7.5.17 crc32slot 分片算法
crc32solt 是有状态分片算法的实现之一，crc32(key)%102400=slot，slot 按照范围均匀分布在 dataNode 上，针对每张表进行实例化，通过一个文件记录 slot 和节点映射关系，迁移过程中通过 zk 协调其中需要在分片表中增加 slot 字段，用以避免迁移时重新计算，只需要迁移对应 slot 数据即可分片最大个数为 102400 个，短期内应该够用，每分片一千万，总共可以支持一万亿数据
八、Mycat常见问题与解决方案
8.1 Mycat 目前有哪些功能与特性？
• 支持 SQL 92 标准；
• 支持 Mysql 集群，可以作为 Proxy 使用；
• 支持 JDBC 连接多数据库；
• 支持 NoSQL 数据库；
• 支持 galera for mysql 集群，percona-cluster 或者 mariadb cluster，提供高可用性数据分片集群；
• 自动故障切换，高可用性；
• 支持读写分离，支持 Mysql 双主多从，以及一主多从的模式；
• 支持全局表，数据自动分片到多个节点，用于高效表关联查询；
• 支持独有的基于 E-R 关系的分片策略，实现了高效的表关联查询；
• 支持一致性 Hash 分片，有效解决分片扩容难题；
多平台支持，部署和实施简单；
• 支持 Catelet 开发，类似数据库存储过程，用于跨分片复杂 SQL 的人工智能编码实现，143 行 Demo 完成
跨分片的两个表的 JION 查询；
• 支持 NIO 与 AIO 两种网络通信机制，Windows 下建议 AIO，Linux 下目前建议 NIO；
• 支持 Mysql 存储过程调用；
• 以插件方式支持 SQL 拦截和改写；
• 支持自增长主键、支持 Oracle 的 Sequence 机制。
8.2 Mycat 除了 Mysql 还支持哪些数据库？
mongodb、oracle、sqlserver 、hive 、db2 、 postgresql。
8.3 Mycat 支持集群么？
目前 Mycat 没有实现对多 Mycat 集群的支持，可以暂时使用 haproxy 来做负载，或者统计硬件负载。
8.4 Mycat 多主切换需要人工处理么？
Mycat 通过心跳检测，自主切换数据库，保证高可用性，无须手动切换。
九、读写分离
9.1 MySQL 主从复制的几种方案
数据库读写分离对于大型系统或者访问量很高的互联网应用来说，是必不可少的一个重要功能。从数据库的角度来说，对于大多数应用来说，从集中到分布，最基本的一个需求不是数据存储的瓶颈，而是在于计算的瓶颈，即 SQL 查询的瓶颈，我们知道，正常情况下，Insert SQL 就是几十个毫秒的时间内写入完成，而系统中的大多数 Select SQL 则要几秒到几分钟才能有结果，很多复杂的 SQL，其消耗服务器 CPU 的能力超强，不亚于死循环的威力。在没有读写分离的系统上，很可能高峰时段的一些复杂 SQL 查询就导致数据库服务器 CPU爆表，系统陷入瘫痪，严重情况下可能导致数据库崩溃。因此，从保护数据库的角度来说，我们应该尽量避免没有主从复制机制的单节点数据库。
对于 MySQL 来说，标准的读写分离是主从模式，一个写节点 Master 后面跟着多个读节点，读节点的数量取
决于系统的压力，通常是 1-3 个读节点的配置，如下图所示：
MySQL 支持更多的主从复制的拓扑关系，如下图所示，但通常我们不会采用双向主从同步以及环状的拓扑：
9.2 MySQL 主从复制的几个问题
MySQL 主从复制并不完美，存在着几个由来已久的问题，首先一个问题是复制方式：
• 基于 SQL 语句的复制(statement-based replication, SBR)；
• 基于行的复制(row-based replication, RBR)；
• 混合模式复制(mixed-based replication, MBR)；
• 基于 SQL 语句的方式最古老的方式，也是目前默认的复制方式，后来的两种是 MySQL 5 以后才出现的复
制方式。
选择哪种方式复制，会影响到复制的效率以及服务器的损耗，甚以及数据一致性性问题，目前其实没有很好
的客观手手段去评估一个系统更适合哪种方式的复制，Mycat 未来希望能通过智能调优模块给出更科学的建议。
第二个问题是关于主从同步的监控问题，Mysql 有主从同步的状态信息，可以通过命令 show slave status获取，除了获知当前是否主从同步正常工作，另外一个重要指标就是 Seconds_Behind_Master，从字面理解，它表示当前 MySQL 主从数据的同步延迟，单位是秒，但这个指标从 DBA 的角度并不能简单的理解为延迟多少秒，但对于应用来说，简单的认为是主从同步的时间差就可以了，另外，当主从同步停止以后，重新启动同步，这个数值可能会是几万秒，取决于主从同步停止的时间长短，我们可以认为数据此时有很多天没有同步了，而这个数值越接近零，则说明主从同步延迟最小，我们可以采集这个指标并汇聚曲线图，来分析我们的数据库的同步延迟曲线，然后根据此曲线，给出一个合理的阀值，主从同步的时延小于阀值时，我们认为从库是同步的，此时可以安全的从从库读取数据。Mycat 未来将支持这种优化，让应用更加可靠的读取到预期的从库数据。
十、高可用与集群
10.1 MySQL 高可用的几种方案
10.1.1 主从复制+读写分离
对于数据实时性要求不是特别严格的应用，只需要通过廉价的 pc server 来扩展 Slave 的数量，将读压力分散到多台 Slave 的机器上面，即可通过分散单台数据库服务器的读压力来解决数据库端的读性能瓶颈，毕竟在大多数数据库应用系统中的读压力还是要比写压力大很多。这在很大程度上解决了目前很多中小型网站的数据库压力瓶颈问题，甚至有些大型网站也在使用类似方案解决数据库瓶颈。
10.1.2 MySQL Cluster
重启 MySQLCluster 数据库的管理操作之前需要执行 46 个手动命令，需要耗费 DBA 2.5 小时的时间，而依靠 MySQLCluster Manager 只需一个命令即可完成，但 MySQL Cluster Manager 仅作为商用 MySQL Cluster 运营商级版本 (CGE) 数据库的一部分提供，需要购买。其官方的说明，若应用中的 SQL 操作为主键数据库访问，包含一些JOIN 操作而非对整个表执行常规扫描和 JOIN 而返回数万行数据，则适合 Cluster，否则不合适，从这一条限制来看，表明大多数业务场景并不合适 MySQL Cluster，业内有资深人士也凭评价：NDB 不适合大多数业务场景，而且有安全问题。
10.1.3 HeartBeat+双主复制
heartbeat 是 Linux-HA 工程的一个组件,heartbeat 最核心的包括两个部分：心跳监测和资源接管。在指定的时间内未收到对方发送的报文，那么就认为对方失效，这时需启动资源接管模块来接管运 行在对方主机上的资源或者服务。
10.1.4 HeartBeat+DRBD+MySQL
DRBD 是通过网络来实现块设备的数据镜像同步的一款开源 Cluster 软件，它自动完成网络中两个不同服务器上的磁盘同步，相对于 binlog 日志同步，它是更底层的磁盘同步，理论上 DRDB 适合很多文件型系统的高可用。
10.1.5 LVS+Keepalived+双主复制
Lvs 是一个虚拟的服务器集群系统，可以实现 LINUX 平台下的简单负载均衡。keepalived 是一个类似于layer3, 4 & 5 交换机制的软件，主要用于主机与备机的故障转移，这是一种适用面很广的负载均衡和高可用方案，最常用于 Web 系统。
10.1.6 MariaDB Galera
这种 gluster 模式可以说是全新的一种高可用方案，前面也提到其优点，它的缺点不多，不支持 XA，不支持
Lock Table，只能用 InnoDB 引擎。
10.2 Mycat 高可用方案
Mycat 作为一个代理层中间件，Mycat 系统的高可用涉及到 Mycat 本身的高可用以及后端 MySQL 的高可用，前面所讲的 MySQL 高可用方案都可以在此用来确保 Mycat 所连接的后端 MySQL 服务的高可用性。在大多数情况下，建议采用标准的 MySQL 主从复制高可用性配置并交付给 Mycat 来完成后端 MySQL 节点的主从自动切换。
如图所示，MySQL 节点开启主从复制的配置方案，并将主节点配置为 Mycat 的 dataHost 里的 writeNode，从节点配置为 readNode，同时 Mycat 内部定期对一个 dataHost 里的所有 writeHost 与 readHost 节点发起心跳检测，正常情况下，Mycat 会将第一个 writeHost 作为写节点，所有的 DML SQL 会发送给此节点，若Mycat开启了读写分离，则查询节点会根据读写分离的策略发往 readHost(+writeHost)执行，当一个 dataHost 里面配置了两个或多个 writeHost 的情况下，如果第一个 writeHost 宕机，则 Mycat 会在默认的 3 次心跳检查失败后，自动切换到下一个可用的 writeHost 执行 DML SQL 语句，并在 conf/dnindex.properties 文件里记录当前所用的 writeHost 的 index（第一个为 0，第二个为 1，依次类推），注意，此文件不能删除和擅自改变，除非你深刻理解了它的作用以及你的目的。
那么问题来了，当原来配置的 MySQL 写节点宕机恢复以后，怎么重新加入 Mycat，要不要恢复为原来的写节点？关于这个问题，我们也曾与 DBA 讨论很久，最终的建议方案是，保持现有状态不变，改旗易帜，恢复后的MySQL节点作为从节点，跟随新的主节点，重新配置主从同步，原先跟随该节点做同步的其他节点也同样换帅，重新配置同步源，这些节点的数据手工完成同步以后，再加入 Mycat 里。目前 1.3 版本的 Mycat 还没有实现监控MySQL 主从同步状态的功能，因此这个过程里，DBA 可以先修改 MySQL 的密码，让 Mycat 无法链接故障服务器，等同步完成以后，恢复密码，这样 Mycat 就自动重新将修复好的 Mycat 纳管进来了。
说完了 MySQL 部分，接下来我们看看 Mycat 自身的高可用性，由于 Mycat 自身是属于无状态的中间件（除了主从切换过程中记录的 dnindex.properties 文件），因此 Mycat 很容易部署为集群方式，提供高可用案。原先有规划 Mycat-balance 组件，专门用于 Mycat 负载均衡，但由于缺乏志愿者，也没有经过生产实践证，因此暂时不建议使用，官方建议是采用基于硬件的负载均衡器或者软件方式的 HAproxy，HAProxy 相比 LVS 的使用要简单很多，功能方面也很丰富，免费开源，稳定性也是非常好，可以与 LVS 相媲美，根据官方文档，HAProxy 可以跑满 10Gbps-New benchmark of HAProxy at 10 Gbps using Myricom’s 10GbE NICs (Myri10G PCI-Express)，这个作为软件级负载均衡，也是比较惊人的，下图是 HAproxy+Mycat 集+MySQL 主从所组成的高可用性方案：
如果还担心 HAproxy 的稳定性和单点问题，则可以用 keepalived 的 VIP 的浮动功能，加以强化：