概述

Mycat是基于阿里Cobar演变而来的一款开源分布式数据库中间件，是一个实现了MySQL协议的Server。前端用户可以把它看做是一个数据库代理，用MySQL客户端工具和命令行访问；而其后端可以用MySQL原生（Native）协议与多个MySQL服务器通信，也可以用JDBC协议与大多数主流数据库服务器通信。

优点：

1. 支持Mysql集群，可以作为Proxy使用；
2. 支持JDBC连接ORACLE、DB2、SQL Server，将其模拟为MySQL Server使用；
3. 自动故障切换，高可用性；
4. 支持读写分离，支持Mysql双主多从，以及一主多从的模式 ，支持全局表，数据自动分片到多个节点，用于高效表关联查询；
5. 支持独有的基于E-R 关系的分片策略，实现了高效的表关联查询；
6. 多平台支持，部署和实施简单。

缺点：

mycat不支持二维路由，仅支持单库多表或多库单表。由于自定义连接池，这样就会存在mycat自身维护一个连接池，MySQL也有一个连接池，任何一个连接池上限都会成为性能的瓶。

mycat架构

mycat.png

mycat利用Mysql的通讯协议模拟成Mysql Server，建立Schema（数据库）、Table （数据表）、User(用户)的逻辑模型，并将这套逻辑模型映射到后端的存储节点DataNode（MySQL Instance）上的真实物理数据库中，这样使得所有能使用Mysql的客户端将mycat当成是Mysql Server来使用。

工作原理

Mycat通过拦截用户发送过来的SQL语句，并对其做一些特定的分析，然后将该SQL发到后端的真实数据库，并将返回的结果做完处理后，最终返回给用户。特定的分析内容如下：

• 分片分析
• 路由分析
• 读写分离分析
• 缓存分析

当Mycat收到一个SQL时，会先解析这个SQL，查找涉及到的表，然后check此表的定义：

• 如果有分片规则，则获取到SQL里分片字段的值，并匹配分片函数，得到该SQL对应的分片列表，然后将SQL发往这些分片去执行，最后收集和处理所有分片返回的结果数据，并输出到客户端。
• 以select * from table where city=?语句为例，查到city=beijing，按照分片函数，beijing返回dn1，于是SQL就发给了MySQL1，去取DB1上的查询结果，并返回给用户。

分片策略(分表分库)

MyCAT通过定义表的分片规则来实现分片，每个表格可以捆绑一个分片规则，每个分片规则指定一个分片字段并绑定一个函数，来实现动态分片算法。

• Schema：逻辑库，与MySQL中的Database（数据库）对应，一个逻辑库中定义了所包括的Table。
• Table：表，即物理数据库中存储的某一张表，与传统数据库不同，这里的表格需要声明其所存储的逻辑数据节点DataNode。在此可以指定表的分片规则。
• DataNode：MyCAT的逻辑数据节点，是存放table的具体物理节点，也称之为分片节点，通过DataSource来关联到后端某个具体数据库上
• DataSource：定义某个物理库的访问地址，用于捆绑到Datanode上

分片规则

• 分片枚举：通过在配置文件中配置可能的枚举 id，自己配置分片，本规则适用于特定的场景，比如有些业务需要按照省份或区县来做保存，而全国省份区县固定的，这类业务使用本条规则；
• 固定分片 hash 算法：本条规则类似于十进制的求模运算，区别在于是二进制的操作,是取 id 的二进制低 10 位，即 id 二进制 &1111111111。 此算法的优点在于如果按照 10 进制取模运算，在连续插入 1-10 时候 1-10 会被分到 1-10 个分片，增大了插入的事务控制难度，而此算法根据二进制则可能会分到连续的分片，减少插入事务事务控制难度；
• 按日期分片：此规则为按天分片。 按单月小时拆分 此规则是单月内按照小时拆分，最小粒度是小时，可以一天最多 24 个分片，最少 1 个分片，一个月完后下月从头开始循环。每个月月尾，需要手工清理数据；
• 截取数字 hash 解析：此规则是截取字符串中的 int 数值 hash 分片；
• 日期范围 hash 分片：思想与范围求模一致，当由于日期在取模会有数据集中问题，所以改成 hash 方法。 先根据日期分组，再根据时间 hash 使得短期内数据分布的更均匀。 优点可以避免扩容时的数据迁移，又可以一定程度上避免范围分片的热点问题。要求日期格式尽量精确些，不然达不到局部均匀的目的；
• 一致性 hash：一致性哈希主要应用于分布式集群对机器添加、删除的管理 1 按照常用hash算法将要管理的对象映射到一个2^32-1的闭合环形上 2 按照常用hash算法将机器映射也映射到此闭合环形上 3 以顺时针计算，将要管理的对象纳入离自己最近的机器上；
• 删除节点时，该机器存储的对象按照顺时针就近原理分配到临近机器上；
• 增加节点时，按照哈希算法获得机器hash值，然后把临近对象分配到该节点；
• 通过虚拟节点方式，增加hash环节点的密集度，保障平衡性。

特性：
•平衡性：各节点的对象个数相对均衡
•单调性：新对象加入时不影响原对象的存储位置
•分散性：相同内容会被分散到相同节点
•负载：同一个节点不能被不同用户映射不同内容

读写分离

读写分离对于大型网站来说，是必不可少的一个重要feature。对于MySQL来说，标准的读写分离是一主多从模式，一个写节点Master后面跟着多个读节点，读节点的数量取决于业务系统的压力，通常是1-n个读节点。Mycat读写分离和自动切换机制，需要其主从架构模式配合。

mysql主从架构

• 主DB server和从DB server数据库的版本一致；
• 主DB server和从DB server数据库数据一致[ 这里就会可以把主的备份在从上还原，也可以直接将主的数据目录拷贝到从的相应数据目录；
• 主DB server开启二进制日志,主DB server和从DB server的server_id都必须唯一。

mycat分布式事务解决方案

1. 准备阶段：事务管理器给每个资源管理器发送准备消息，每个参与者要么直接返回失败(如权限验证失败)，要么在本地执行事务，写本地的redo和undo日志但不提交：

• 事务管理器向所有资源管理器询问是否可以执行提交操作(vote)，并开始等待各资源管理器的响应。
• 资源管理器执行询问发起为止的所有事务操作，并将Undo信息和Redo信息写入日志。
• 各资源管理器响应事务管理器发起的询问。如果资源管理器的事务操作实际执行成功，则它返回一个”同意”消息；如果资源管理器的事务操作实际执行失败，则它返回一个”中止”消息。
  提交阶段：如果事务管理器收到了参与者的失败消息或者超时，直接给每个资源管理器发送回滚(Rollback)消息，否则发送提交(Commit)消息，资源管理器根据事务管理器的指令执行提交或者回滚操作，释放所有事务处理过程中使用的锁资源。
  二阶段提交所存在缺点的：
• 同步阻塞问题，执行过程中所有资源管理器都是事务阻塞型的，当资源管理器占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态；
• 单点故障，由于事务管理器的重要性一旦事务管理器发生故障资源管理器会一直阻塞下去。
• 数据不一致，在二阶段提交的阶段二中，当事务管理器向资源管理器发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中事务管理器发生了故障，导致只有一部分资源管理器接受到了commit请求，而在这部分资源管理器接到commit请求之后就会执行commit操作，但是其他部分未接到commit请求的机器则无法执行事务提交，于是整个分布式系统便出现了数据不一致性的现象。

mycat不适用场景

• 非分片字段查询：
  如果该分片字段选择度高，也是业务常用的查询维度，一般只有一个或极少数个DB节点命中，会极大消耗Mycat和MySQL数据库资源；
• 分页排序：
  Mycat向应用返回的结果集取决于哪个DB节点最先返回结果给Mycat。
  如果Mycat最先收到DB1节点的结果集，那么Mycat返回给应用端的结果集为 [0,1]。
  如果Mycat最先收到DB2节点的结果集，那么返回给应用端的结果集为 [5,6]。
  也就是说，相同情况下，同一个SQL，在Mycat上执行时会有不同的返回结果；
• 任意表JOIN：无法跨库join；
• 分布式事务：Mycat并没有根据二阶段提交协议实现XA事务，而是只保证 prepare 阶段数据一致性的弱XA事务。