【总结】MyCat分布式数据库中间件

1，数据库概述

• 在互联网时代，海量数据的存储与访问成为系统设计与使用的瓶颈问题，对于海量数据处理，按照使用场景，主要分为两种类型
• • 联机事务处理（OLTP：On-line transaction processing）： 也称为面向交易的处理系统，其基本特征是原始数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果
  • • 功能：日常交易处理
    • DB设计：面向实时交易类应用
    • 数据处理：当前的，最新的细节的，二维的分立的
    • 实时性：实时读写要求高
    • 事务：强一致性
    • 分析要求：低，简单
  • 联机分析处理（OLAP： On-Line Analytical Processing）： 是指通过多维的方式对数据进行分析、查询和报表，可以同数据挖掘工具、统计分析工具配合使用，增强决策分析功能
  • • 功能：统计，分析，报表
    • DB设计：面向统计分析类应用
    • 数据处理：历史的，聚集的，多维的集成的，统一的
    • 实时性：实时读写要求低
    • 事务：弱事务
    • 分析要求：高，复杂
• 针对上面两类系统有多种技术实现方案，存储部分的数据库主要分为两大类：关系型数据库与NoSQL数据库
• • 关系型数据库 ，是建立在关系模型基础上的数据库，其借助于集合代数等数学概念和方法来处理数据库中的数据
  • • 代表
    • • 主流的Oracle、DB2、MS SQL Server和MySQL
    • 特点
    • • 数据关系模型基于关系模型，结构化存储，完整性约束
      • 基于二维表及其之间的联系，需要连接、并、交、差、除等数据操作
      • 采用结构化的查询语言（SQL）做数据读写
      • 操作需要数据的一致性，需要事务甚至是强一致性
    • 优点
    • • 保持数据的一致性（事务处理）
      • 可以进行join等复杂查询
      • 通用化，技术成熟
    • 缺点
    • • 数据读写必须经过sql解析，大量数据、高并发下读写性能不足
      • 对数据做读写，或修改数据结构时需要加锁，影响并发操作
      • 无法适应非结构化存储
      • 扩展困难
      • 昂贵、复杂
  • NoSQL数据库 ，全称为Not Only SQL，意思就是适用关系型数据库的时候就使用关系型数据库，不适用的时候也没有必要非使用关系型数据库不可，可以考虑使用更加合适的数据存储
  • • 代表
    • • 临时性键值存储（memcached、Redis）
      • 永久性键值存储（ROMA、Redis）
      • 面向文档的数据库（MongoDB、CouchDB）
      • 面向列的数据库（Cassandra、HBase）
    • 特点
    • • 非结构化的存储
      • 基于多维关系模型
      • 具有特有的使用场景
    • 优点
    • • 高并发，大数据下读写能力较强
      • 基本支持分布式，易于扩展，可伸缩
      • 简单，弱结构化存储
    • 缺点
    • • join等复杂操作能力较弱
      • 事务支持较弱
      • 通用性差
      • 无完整约束复杂业务场景支持较差

2，MyCat概述

• 功能
• • DBA
  • • Mycat就是MySQL Server，而Mycat后面连接的MySQL Server，就好象是MySQL的存储引擎,如InnoDB，MyISAM等，因此，Mycat本身并不存储数据，数据是在后端的MySQL上存储的，因此数据可靠性以及事务等都是MySQL保证的
  • 工程师
  • • Mycat就是一个近似等于MySQL的数据库服务器，你可以用连接MySQL的方式去连接Mycat（除了端口不同，默认的Mycat端口是8066而非MySQL的3306，因此需要在连接字符串上增加端口信息）
    • 大多数情况下，可以用你熟悉的对象映射框架使用Mycat，但建议对于分片表，尽量使用基础的SQL语句，因为这样能达到最佳性能，特别是几千万甚至几百亿条记录的情况下
  • 架构师
  • • Mycat是一个强大的数据库中间件，不仅仅可以用作读写分离、以及分表分库、容灾备份，而且可以用于多租户应用开发、云平台基础设施、让你的架构具备很强的适应性和灵活性，借助于即将发布的Mycat智能优化模块，系统的数据访问瓶颈和热点一目了然，根据这些统计分析数据，你可以自动或手工调整后端存储，将不同的表映射到不同存储引擎上，而整个应用的代码一行也不用改变
• 原理
• • Mycat的原理中最重要的一个动词是“拦截”，它拦截了用户发送过来的SQL语句，首先对SQL语句做了一些特定的分析：如分片分析、路由分析、读写分离分析、缓存分析等，然后将此SQL发往后端的真实数据库，并将返回的结果做适当的处理，最终再返回给用户
• 应用场景
• • 单纯的读写分离，此时配置最为简单，支持读写分离，主从切换
  • 分表分库，对于超过1000万的表进行分片，最大支持1000亿的单表分片
  • 多租户应用，每个应用一个库，但应用程序只连接Mycat，从而不改造程序本身，实现多租户化
  • 报表系统，借助于Mycat的分表能力，处理大规模报表的统计
  • 替代Hbase，分析大数据
  • 作为海量数据实时查询的一种简单有效方案，比如100亿条频繁查询的记录需要在3秒内查询出来结果，除了基于主键的查询，还可能存在范围查询或其他属性查询，此时Mycat可能是最简单有效的选择

3，MyCat概念

• 数据库中间件
• • MyCat是数据库中间件，就是介于数据库与应用之间，进行数据处理与交互的中间服务。由于前面讲的对数据进行分片处理之后，从原有的一个库，被切分为多个分片数据库，所有的分片数据库集群构成了整个完整的数据库存储
  • 有了数据库中间件，应用只需要集中与业务处理，大量的通用的分片集群，数据源切换、事务处理、数据聚合都由中间件来处理
• 逻辑库
• • 对实际应用来说，并不需要知道中间件的存在，业务开发人员只需要知道数据库的概念，所以数据库中间件可以被看做是一个或多个数据库集群构成的逻辑库
• 逻辑表
• • 逻辑表
  • • 分布式数据库中，对应用来说，读写数据的表就是逻辑表。逻辑表，可以是数据切分后，分布在一个或多个分片库中，也可以不做数据切分，不分片，只有一个表构成
  • 分片表
  • • 是指那些原有的很大数据的表，需要切分到多个数据库的表，这样，每个分片都有一部分数据，所有分片构成了完整的数据
    • 通过<table>的dataNode配置多个分片节点
  • 非分片表
  • • 一个数据库中并不是所有的表都很大，某些表是可以不用进行切分的， 非分片是相对分片表来说的，就是那些不需要进行数据切分的表
    • 通过<table>的dataNode配置一个分片节点
  • ER表
  • • 基于E-R关系的数据分片策略，子表的记录与所关联的父表记录存放在同一个数据分片上，即子表依赖于父表，通过表分组（Table Group）保证数据Join不会跨库操作
    • 表分组（Table Group） 是解决跨分片数据join的一种很好的思路，也是数据切分规划的重要一条规则
  • 全局表
  • • 一个真实的业务系统中，往往存在大量的类似字典表的表，这些表基本上很少变动，字典表具有以下几个特性
    • • 变动不频繁
      • 数据量总体变化不大
      • 数据规模不大，很少有超过数十万条记录
    • 对于这类的表，在分片的情况下，当业务表因为规模而进行分片以后，业务表与这些附属的字典表之间的关联，就成了比较棘手的问题，所以MyCat中通过数据冗余来解决这类表的join，即所有的分片都有一份数据的拷贝，所有将字典表或者符合字典表特性的一些表定义为 全局表
    • 数据冗余是解决跨分片数据join的一种很好的思路，也是数据切分规划的另外一条重要规则
• 分片节点
• • 分片节点(dataNode)
  • • 数据切分后，一个大表被分到不同的分片数据库上面，每个表分片所在的数据库就是分片节点（ dataNode）
  • 节点主机(dataHost)
  • • 数据切分后，每个分片节点（ dataNode）不一定都会独占一台机器，同一机器上面可以有多个分片数据库，这样一个或多个分片节点（ dataNode）所在的机器就是节点主机（ dataHost）,为了规避单节点主机并发数限制，尽量将读写压力高的分片节点（dataNode）均衡的放在不同的节点主机（ dataHost）
  • 分片规则(rule)
  • • 前面讲了数据切分，一个大表被分成若干个分片表，就需要一定的规则，这样按照某种业务规则把数据分到某个分片的规则就是分片规则 ，数据切分选择合适的 分片规则非常重要，将极大的避免后续数据处理的难度
  • 全局序列号(sequence)
  • • 数据切分后，原有的关系数据库中的主键约束在分布式条件下将无法使用，因此需要引入外部机制保证数据唯一性标识，这种保证全局性的数据唯一标识的机制就是全局序列号（sequence）
  • 多租户：多租户技术 或称多重租赁技术，是一种软件架构技术，它是在探讨与实现如何于多用户的环境下共用相同的系统或程序组件，并且仍可确保各用户间数据的隔离性
  • • 独立数据库
    • 共享数据库，隔离数据架构
    • 共享数据库，共享数据架构

4，MyCat使用

• MyCat配置
• • schema.xml
  • • 管理着MyCat的逻辑库、表、分片规则、DataNode以及DataSource
    • schema标签
    • • 用于定义MyCat实例中的逻辑库
      • MyCat可以有多个逻辑库，每个逻辑库都有自己相关配置
    • table标签
    • • Table标签定义了MyCat的逻辑表，所有需要拆分的表都需要在这个标签中定义
    • dataNode标签
    • • 定义这个逻辑表所属的dataNode, 该属性的值需要和dataNode标签中name属性的值相互对应
    • dataHost
    • • 作为Schema.xml中最后的一个标签，该标签在mycat逻辑库中也是作为最底层的标签存在，直接定义了具体的数据库实例、读写分离配置和心跳语句
  • server.xml
  • • server.xml几乎保存了所有mycat需要的系统配置信息
    • 优化配置
    • user标签
    • system标签
  • rule.xml
  • • rule.xml里面就定义了我们对表进行拆分所涉及到的规则定义。我们可以灵活的对表使用不同的分片算法，或者对表使用相同的算法但具体的参数不同
    • tableRule标签
    • • 这个标签定义表规则
    • function标签
• 表关联问题（表Join）
• • Join概述
  • • Inner Join：交集
    • Left Join
    • Right Join
    • Full Join：并集
    • 建议使用Inner Join
  • 全局表
  • • 字典表
    • • 变动不频繁
      • 数据量总体变化不大
      • 数据规模不大，很少有超过数十万条记录
    • 全局表特性
    • • 全局表的插入、更新操作会实时在所有节点上执行，保持各个分片的数据一致性
      • 全局表的查询操作，只从一个节点获取
      • 全局表可以跟任何一个表进行JOIN操作
  • ER Join
  • • 基于E-R关系的数据分片策略，子表的记录与所关联的父表记录存放在同一个数据分片上
  • Share Join
  • • ShareJoin是一个简单的跨分片Join,基于HBT的方式实现
    • 目前支持2个表的join,原理就是解析SQL语句，拆分成单表的SQL语句执行，然后把各个节点的数据汇集
  • Catlet（人工智能）
  • • 解决跨分片的SQL JOIN的问题，远比想象的复杂，而且往往无法实现高效的处理，既然如此，就依靠人工的智力，去编程解决业务系统中特定几个必须跨分片的SQL的JOIN逻辑，MyCAT提供特定的API供程序员调用，这就是MyCAT创新性的思路——人工智能
• MyCat分片规则
• • 概述
  • • 在数据切分处理中，特别是水平切分中，中间件最终要的两个处理过程就是数据的切分、数据的聚合。选择合适的切分规则，至关重要，因为它决定了后续数据聚合的难易程度，甚至可以避免跨库的数据聚合处理
    • 重要的几条原则，其中有几条是数据冗余，表分组（Table Group） ，这都是业务上规避跨库join的很好的方式，但不是所有的业务场景都适合这样的规则，因此本章将讲述如何选择合适的切分规则
    • 几种分片
    • • MyCat全局表
      • ER分片表
      • 多对多关联
      • • 总的原则是需要从业务角度来看，关系表更偏向哪个表
      • 主键分片vs 非主键分片
      • • 当你没任何字段可以作为分片字段的时候，主键分片就是唯一选择，其优点是按照主键的查询最快，当采用自动增长的序列号作为主键时，还能比较均匀的将数据分片在不同的节点上
        • 若有某个合适的业务字段比较合适作为分片字段，则建议采用此业务字段分片，选择分片字段的条件如下
        • • 尽可能的比较均匀分布数据到各个节点上
          • 该业务字段是最频繁的或者最重要的查询条件
  • MyCat常用分片规则
  • • 分片枚举
    • • 比如有些业务需要按照省份或区县来做保存，而全国省份区县固定的
    • 固定分片Hash算法
    • • 本条规则类似于十进制的求模运算，区别在于是二进制的操作,是取id的二进制低10位，即id二进制&1111111111。此算法的优点在于如果按照10进制取模运算，在连续插入1-10时候1-10会被分到1-10个分片，增大了插入的事务控制难度，而此算法根据二进制则可能会分到连续的分片，减少插入事务控制难度
    • 求模
    • • 此规则为对分片字段求摸运算
      • 此种配置非常明确即根据id进行十进制求模预算，相比固定分片hash，此种在批量插入时可能存在批量插入单事务插入多数据分片，增大事务一致性难度
    • 按日期（天）分片
    • • 此规则为按天分片
      • 此种规则是取模运算与范围约束的结合，主要为了后续数据迁移做准备，即可以自主决定取模后数据的节点分布
    • 取模范围约束
    • • 此种规则是取模运算与范围约束的结合，主要为了后续数据迁移做准备，即可以自主决定取模后数据的节点分布
    • ASCII码求模范围约束
    • • 此种规则类似于取模范围约束，此规则支持数据符号字母取模
    • 字符串Hash解析
    • • 此规则是截取字符串中的int数值hash分片
    • 一致性Hash
    • • 一致性Hash预算有效解决了分布式数据的扩容问题
    • 按单月小时拆分
    • • 此规则是单月内按照小时拆分，最小粒度是小时，可以一天最多24个分片，最少1个分片，一个月完后下月从头开始循环。每个月月尾，需要手工清理数据
    • 自然月分片
    • • 按月份列分区 ，每个自然月一个分片，格式 between操作解析的范例

5，MyCat高级功能

• 读写分离
• • MySQL主从复制方案
  • • Master to Slave
    • Master to Multiple Slaves
    • Multi-Master
    • Master to Slaves to Slaves
    • Multi-Master Ring
  • 主从复制问题
  • • 复制方式
    • • 基于SQL语句的复制(statement-based replication, SBR)
      • 基于行的复制(row-based replication, RBR)
      • 混合模式复制(mixed-based replication, MBR)
      • 基于SQL语句的方式最古老的方式，也是目前默认的复制方式，后来的两种是MySQL 5以后才出现的复制方式
    • 基于行的复制 RBR
    • • 优点
      • • 任何情况都可以被复制，这对复制来说是最安全可靠的
        • 和其他大多数数据库系统的复制技术一样
        • 多数情况下，从服务器上的表如果有主键的话，复制就会快了很多
      • 缺点
      • • binlog 大了很多
        • 复杂的回滚时 binlog 中会包含大量的数据
        • 主服务器上执行 UPDATE 语句时，所有发生变化的记录都会写到 binlog 中，而 SBR 只会写一次，这会导致频繁发生binlog 的并发写问题
        • 无法从 binlog 中看到都复制了写什么语句
    • 基于SQL语句的复制 SBR
    • • 优点
      • • 历史悠久，技术成熟
        • binlog文件较小
        • binlog中包含了所有数据库更改信息，可以据此来审核数据库的安全等情况
        • binlog可以用于实时的还原，而不仅仅用于复制
        • 主从版本可以不一样，从服务器版本可以比主服务器版本高
      • 缺点
      • • 不是所有的UPDATE语句都能被复制，尤其是包含不确定操作的时候
        • 复制需要进行全表扫描(WHERE 语句中没有使用到索引)的 UPDATE 时，需要比 RBR 请求更多的行级锁
        • 对于一些复杂的语句，在从服务器上的耗资源情况会更严重，而 RBR 模式下，只会对那个发生变化的记录产生影响
        • 数据表必须几乎和主服务器保持一致才行，否则可能会导致复制出错
        • 执行复杂语句如果出错的话，会消耗更多资源
  • MyCat主从复制
  • • 通过writeHost和readHost配置
• 高可用和集群
• • MySQL高可用几种方案
  • • 主从复制 + 读写分离
    • • 客户端通过Master进行写操作
      • Slave进行读操作，并可进行备份
      • Master出问题后，手动将应用切换到slave端
    • MySQL Cluster
    • • MySQL Cluster由一组计算机构成，每台计算机上均运行着多种进程，包括MySQL服务器，NDB Cluster 的数据节点，管理服务器，以及（可能）专门的数据访问程序
      • NDB” 是一种“内存中”的存储引擎，它具有可用性高和数据一致性好的特点
      • MySQL Cluster要实现完全冗余和容错，至少需要4台物理主机，其中两个为管理节点
      • MySQL Cluster使用不那么广泛，除了自身构架因素、适用的业务有限之外，另一个重要的原因是其安装配置管理相对复杂繁琐，总共有几十个操作步骤，需要DBA花费几个小时才能搭建或完成。重启 MySQL Cluster 数据库的管理操作之前需要执行 46 个手动命令，需要耗费 DBA 2.5 小时的时间
    • HeartBeat + 双主复制
    • • heartbeat是Linux-HA工程的一个组件,heartbeat最核心的包括两个部分：心跳监测和资源接管。在指定的时间内未收到对方发送的报文，那么就认为对方失效，这时需启动资源接管模块来接管运行在对方主机上的资源或者服务
    • HeartBeat + DRBD + MySQL
    • • DRBD是通过网络来实现块设备的数据镜像同步的一款开源Cluster软件，它自动完成网络中两个不同服务器上的磁盘同步，相对于binlog日志同步，它是更底层的磁盘同步，理论上DRDB适合很多文件型系统的高可用
    • Lvs + Keeplived + 双主复制
    • • Lvs是一个虚拟的服务器集群系统，可以实现LINUX平台下的简单负载均衡。keepalived是一个类似于layer3, 4 & 5交换机制的软件，主要用于主机与备机的故障转移，这是一种适用面很广的负载均衡和高可用方案，最常用于Web系统
    • MariaDB Galera
    • • 这种gluster模式可以说是全新的一种高可用方案，前面也提到其优点，它的缺点不多，不支持XA，不支持Lock Table，只能用InnoDB引擎
  • MyCat高可用方案
  • • 建议采用标准的MySQL主从复制高可用性配置并交付给Mycat来完成后端MySQL节点的主从自动切换
    • HAProxy相比LVS的使用要简单很多，功能方面也很丰富，免费开源，稳定性也是非常好，可以与LVS相媲美
    • 推荐：HAProxy+ MyCat集群 + MySQL主从所组成的高可用性方案
    • 如果担心HAproxy的稳定性和单点问题，则可以用Keepalived的VIP的浮动功能，加以强化
• 事务支持
• • MyCat支持的事务
  • • 单SQL不垮分片：事务中的单条SQL在单个节点上执行
    • 单SQL跨分片：事务中的单条SQL在多个节点上执行
    • 事务内多个SQL，在不同的分片上执行
  • XA（两阶段提交方式来管理分布式事务 ）事务
  • XA事务和MySQL的局限
  • • MySQL数据库的主备数据库的同步，通过Binlog的复制完成。而Binlog是MySQL数据库内部XA事务的协调者，并且MySQL数据库为binlog做了优化——binlog不写prepare日志，只写commit日志。所有的参与节点prepare完成，在进行xacommit前crash。crash recover如果选择commit此事务。由于binlog在prepare阶段未写，因此主库中看来，此分布式事务最终提交了，但是此事务的操作并未写到binlog中，因此也就未能成功复制到备库，从而导致主备库数据不一致的情况出现
• MyCat-Web
• • 对server端进行管理与监控
  • MyCat-Web 数据库连接设计：采用了基于代码方式向Spring IOC中注册一个DataSource。因此他能管理你所有的mycat、mysql服务
  • MyCat-Web监控：由开源的jrds实现。目前已经实现了Mycat、Mysql性能监控(jdbc连接获取)、Mycat的JVM内存、线程的监控(通过JMX获取)，Mycat,Mysql所在操作系统的CPU、内存、磁盘、网络的监控。(通过SNMP协议获取)

6，MyCat生产案例

7，MyCat原理分析

• 整体结构

• 线程模型