数据库中间件Mycat自我介绍
一、mycat概述
1.功能介绍
mycat一个开源的分布式数据库系统,是一个实现了mysql协议的server前端用户可以把它看成一个数据库代理,用mysql客户端工具和命令行访问,后端可以用mysql原生（native）协议与多个mysql服务器通信,也可以JDBC协议与大多数主流的数据库服务器通信.其核心功能是分表分库.即把一个大表水平分割为N个小表;存储在后端mysql服务器或者其他数据库里.
严格意义上,由于真正的数据库需要有存储引擎,而mycat并没有存储引擎;Mycat是数据库中间件,就是介于数据库和分布式数据库系统之间的服务.
JDBC说明：
JDBC API是一个Java API，可以访问任何类型表列数据，特别是存储在关系数据库中的数据。JDBC代表Java数据库连接。
JDBC库中所包含的API任务通常与数据库使用：
1)连接到数据库
2)创建SQL或MySQL语句
3)在数据库中执行SQL或MySQL查询
4)查看和修改记录
1.1Mycat是什么？
基于阿里开源的Cobar产品而研发的一款专注数据库分库分表中间件,Mycat是数据库的中间件,介于数据库和应用之间进行数据处理与交互的中间服务;其实Mycat就是BigSQL，Big Data On SQL Database.
官方概述：
一个彻底开源的，面向企业应用开发的大数据库集群
支持事务、ACID、可以替代MySQL的加强版数据库
一个可以视为MySQL集群的企业级数据库，用来替代昂贵的Oracle集群
一个融合内存缓存技术、NoSQL技术、HDFS大数据的新型SQL Server
结合传统数据库和新型分布式数据仓库的新一代企业级数据库产品
一个新颖的数据库中间件产品
1.2我们眼中Mycat
对于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智能优化模块,系统的数据访问瓶颈和热点一目了然,根据这些统计分析数据,你可以自动或手工调整后端存储,将不同的表映射到不同存储引擎上,而整个应用的代码一行也不用改变.
当前是个大数据的时代,但究竟怎样规模的数据适合数据库系统呢？对此国外有一个数据库领域的权威人士说了一个结论：
千亿以下的数据规模仍然是数据库领域的专长,而Hadoop等这种系统，更适合的是千亿以上的规模.所以Mycat适合1000亿条以下的单表规模,如果你的数据超过了这个规模,请投靠Mycat Plus吧！
二、Mycat原理说明
Mycat的原理并不复杂，复杂的是代码,如果代码也不复杂,那么早就成为一个传说了.
Mycat的原理中最重要的一个动词是”拦截”,它拦截了用户发送过来的SQL语句,首先对SQL语句做了一些特定的分析：如分片分析、路由分析、读写分离分析、缓存分析等,然后将此SQL发往后端的真实数据库,并将返回的结果做适当的处理,最终再返回给用户.
上述图片里,Orders表被分为三个分片datanode（简称dn),这三个分片是分布在两台MySQL Server上(DataHost),即datanode=database@datahost方式，因此你可以用一台到N台服务器来分片，分片规则为（sharding rule)典型的字符串枚举分片规则，一个规则的定义是分片字段（sharding column)+分片函数(rule function)，这里的分片字段为prov而分片函数为字符串枚举方式。
当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引擎等十八般武艺的解决办法，从而成为目前业界最强大的方案，这就是开源的力量！
三、Mycat的应用场景
a.单纯的读写分离，此时配置最为简单，支持读写分离，主从切换.
b.分表分库，对于超过1000万的表进行分片，最大支持1000亿的单表分片
c.多租户应用，每个应用一个库，但应用程序只连接Mycat,从而不改造程序本身，实现多租户化.
d.报表系统，借助于Mycat的分表能力，处理大规模报表的统计.
e.代替Hbase,分析大数据.
f.作为海量数据实时查询的一种简单有效方案 比如100亿条频繁查询的记录需要在3秒内查询出来结果,除了基于主键的查询,还可能存在范围查询或其他属性查询，此时Mycat可能是最简单有效的选择.
小结：
--单纯的读写分离,此时配置最为简单,支持读写分离,主从切换分表分库,对于超过1000万的表进行分片,最大支持1000亿的单表分片—多租户应用,每个应用一个库,但应用程序只连接Mycat,从而不改造程序本身,实现多租户化.
--报表系统,借助于Mycat的分表能力,处理大规模报表的统计替代Hbase,分析大数据,作为海量数据实时查询的一种简单有效方案,比如100亿条频繁查询的记录需要在3秒内查询出来结果,除了基于主键的查询,还可能存在范围查询或其他属性查询,此时mycat可能是最简单有效的选择.
四、Mycat涉及到关键词概念
1）数据库中间件：
前面提到Mycat是一个开源的分布式数据库系统，但是由于真正的数据库需要存储引擎，而Mycat并不具备存储引擎，所以真正意义上不是一个分布式数据库系统。
Mycat作为数据库的中间件，介于数据库和应用之间，进行数据处理与交互中间服务。
如上图所表示，数据被分到多个分片数据库后，应用如果需要读取数据，就要需要处理多个数据源的数据。如果没有数据库中间件，那么应用将直接面对分片集群，数据源切换、事务处理、数据聚合都需要应用直接处理，原本该是专注于业务的应用，将会花大量的工作来处理分片后的问题，最重要的是每个应用处理将是完全的重复造*.
所以有了数据库中间件，应用只需要集中与业务处理，大量的通用的数据聚合，事务，数据源切换都由中间件来处理，中间件的性能与处理能力将直接决定应用的读写性能，所以一款好的数据库中间件至关重要.
数据切分
简单来说，就是指通过特定的条件，把我们存放的同一个数据库分散存放到分散列多个数据库（主机）上面，已达到分散单台设备负载的效果。
数据的切分（sharding）依照规则分为两种：
1）垂直切分
按照不同的表（或Schema）来切分到不同数据库（主机）上这种称为数据的垂直（纵向）切分。
特点：
最大的特点就是规则简单，相互影响较小，实施方便。适合各业务中间的耦合度较低的场景。
2）水平切分
依照表中的逻辑关系，将将同一表中的数据按照某种关系拆分到多台数据库（主机）上面，这种切分称为水平（横向）切分。
特点：
相当于垂直切分，稍微复杂一些，因为要将同一表中的不同数据拆分到不同的数据库中，对于程序来说，拆分规则本身较根据表名拆分更为负杂，后期维护也更为复杂一些。
前面讲了垂直切分跟水平切分的不同跟优缺点，会发现每种切分都有缺点，但共同的特点缺点有：
1.引入分布式亊务的问题。
2.跨节点 Join 的问题。
3.跨节点合并排序分页问题。
4.多数据源管理问题。
针对数据源管理，目前主要有两种思路：
A.客户端模式，在每个应用程序模块中配置管理自己需要的一个（或者多个）数据源，直接访问各个数据库，在模块内完成数据的整合；
B. 通过中间代理层来统一管理所有的数据源，后端数据库集群对前端应用程序透明；可能90%以上的人在面对上面这两种解决思路的时候都会倾向于选择第二种，尤其是系统不断变得庞大复杂的时候。确实，这是一个非常正确的选择，虽然短期内需要付出的成本可能会相对更大一些，但是对整个系统的扩展性来讲，是非常有帮助的数据切分的原则：
数据切分的原则：
第一原则：能不切分尽量不要切分。
第二原则：如果要切分一定要选择合适的切分规则，提前规划好。
第三原则：数据切分尽量通过数据冗余或者表分组（Table Group）来降低跨库 Join 的可能。
第四原则：由于数据库中间件对数据 Join 实现的优劣难以把握，而且实现高性能难度极大，业务读取尽量少使用多表 Join
2）逻辑表（table)
既然有逻辑库，那么就会有逻辑表，分布式数据库中，对应用来说，读写数据的表就是逻辑表。逻辑表可以是数据切分后，分布在一个或多个分片库中，也可以不做数据切分，不分片，只有一个表构成。
3）分片表
分片表，是指那些原有的很大数据的表，需要切分到多个数据库的表，这样，每个分片都有一部分数据，所有分片构成了完整的数据。
例如在mycat配置中的t_node就属于分片表，数据按照规则被分到dn1,dn2两个分片节点(dataNode) 上
<table name=nt_noden primaryKey=nvidn autoincrement=ntruen dataNode=ndn1,dn2n rule=nrule1n />
4）非分片表
一个数据库中并不是所有的表都很大，某些表是可以不用进行切分的，非分片是相对分片表来说的，就是那 些不需要进行数据切分的表。
如下配置中t_node ,只存在于分片节点（dataNode ) dn1上。
<table name=nt_noden primaryKey=nvidn autoincrement=ntruen dataNode=ndn1" />
5）ER 表
关系型数据库是基于实体关系模型（Entity-Relationship Model)之上，通过其描述了真实世界中事物与关系，Mycat中的ER表即是来源于此。根据这一思路，提出了基于E-R关系的数捤分片策略，子表的记录与所关联的父表记录存放在同一个数据分片上，即子表依赖于父表，通过表分组（Table Group)保证数据Join不会跨库操作。
表分组（Table Group )是解决跨分片数据join的一种很好的思路，也是数据切分规划的重要一条规则。
7）全局表
一个真实的业务系统中，往往存在大量的类似字典表的表，这些表基本上很少变动，字典表具有以下几个特性：
1.变动不频繁
2.数据量总体变化不大
3.数据规模不大，很少有超过数十万条记录。
7）分片节点(dataNode)
数据切分后，一个大表被分到不同的分片数据库上面，每个表分片所在的数据库就是分片节点 (dataNode )。
8）节点主机(dataHost)
数据切分后，每个分片节点（dataNode)不一定都会独占一台机器，同一机器上面可以有多个分片数据库， 这样一个或多个分片节点（dataNode )所在的机器就是节点主机（dataHost),为了规避单节点主机并发数限 制，尽量将读写压力高的分片节点（dataNode )均衡的放在不同的节点主机（dataHost )。
9）分片规则(rule)
前面讲了数据切分，1个大表被分成若干个分片表，就需要一定的规则，这样按照某种业务规则把数据分到 某个分片的规则就是分片规则，数据切分选择合适的分片规则非常重要，将极大的避免后续数据处理的难度。
10）多租户
多租户技术或称多重租赁技术，是一种软件架构技术，它是在探讨与实现如何于多用户的环境下共用相同的系统或程序组件，并且仍可确保各用户间数据的隔离性。在云计算时代，多租户技术在共用的数据中心以单一系统架构与服务提供多数客户端相同甚至可定制化的服务，并且仍然可以保障客户的数据隔离。目前各种各样的云计算服务就是这类技术范畴，例如阿里云数据库服务（RDS )、阿里云服务器(ECS)等等。
多租户在数据存储上存在3种主要的方案，分别是：
1》独立数据库
即一个租户一个数据库，这种方案的用户数据隔离级别最高，安全性最好，但成本也高。
优点：
1、为不同的租户提供独立的数据库，有助于简化数据模型的扩展设计，满足不同租户的独特需求；
2、如果出现故障，恢复数据比较简单。 缺点：
1、增大了数据库的安装数量，随之带来维护成本和购置成本的增加。
这种方案与传统的一个客户、一套数据、一套部署类似，差别只在于软件统一部署在运营商那里。如果面对的是银行、医院等需要非常高数据隔离级别的租户，可以选择这种模式，提高租用的定价。如果定价较低，产品走低价路线，这种方案一般对运营商来说是无法承受的
2》共享数据库，隔离数据架构
即多个或所有租户共享Database，但是每个租户一个Schema。
优点：
1、为安全性要求较高的租户提供了一定程度的逻辑数据隔离，并不是完全隔离；每个数据库可以支持更多的租户数量。
缺点：
1、如果出现故障，数据恢复比较困难，因为恢复数据库将牵扯到其它租户的数据
2、如果需要跨租户统计数据，存在一定困难。
3》共享数据库，共享数据架构
即租户共享同一个Database、同一个Schema，但在表中通过TenantID区分租户的数据。这是共享程度最高、隔离级别最低的模式。
优点：
1、三种方案比较，第三种方案的维护和购置成本最低，允许每个数据库支持的租户数量最多。
缺点：
1、隔离级别最低，安全性最低，需要在设计开发时加大对安全的开发量；
2、数据备份和恢复最困难，需要逐表逐条备份和还原。
3、如果希望以最少的服务器为最多的租户提供服务，并且租户接受以牺牲隔离级别换取降低成本，这种方案最适合