1、Mycat 应用场景

Mycat 发展到现在，适用的场景已经很丰富，而且不断有新用户给出新的创新性的方案，以下是几个典型的应用场景：

• 1. 单纯的读写分离，此时配置最为简单，支持读写分离，主从切换
• 2. 分表分库，对于超过 1000 万的表进行分片，最大支持 1000 亿的单表分片
• 3. 多租户应用，每个应用一个库，但应用程序只连接 Mycat，从而不改造程序本身，实现多租户化
• 4. 报表系统，借助于 Mycat 的分表能力，处理大规模报表的统计
• 5. 替代 Hbase，分析大数据
• 6. 作为海量数据实时查询的一种简单有效方案，比如 100 亿条频繁查询的记录需要在 3 秒内查询出来结果，除了基于主键的查询，还可能存在范围查询或其他属性查询，此时 Mycat 可能是最简单有效的选择。

MYCAT可以实现读写分离下的读操作负,mycat载均衡，将大量的读操作均衡到不同的从库上，主要出现在一主多从情形下。

MYCAT可实现数据库的高可用，在数据库主节点可用的情况下，配置一台可写从节点，这两个节点都配置在MYCAT中，当主节点宕机时，MyCAT会自动将写操作路由到备用节点上，但并不支持在切换之后的继续主从同步。

当读写分离已经不能满足持续增加的访问量时，MYCAT可实现数据库的垂直拆分，将所有的数据库表按照模块划分，不同类型的表拆分到不同的数据库服务器。

随着业务量的增长，垂直拆分之后如果又出现了数据库性能问题，则需要进行水平切分，这就是俗称的分库分表。将数据量很大的表数据切分到不同的服务器库中，表结构是一样的，而使用MYCAT实现水平切分，对前端应用是完全透明的，不用调整前台逻辑。

从定义和分类来看，它是一个开源的分布式数据库系统，是一个实现了MySQL协议的服务器，前端用户可以把它看作是一个数据库代理，用MySQL客户端工具和命令行访问，而其后端可以用MySQL原生协议与多个MySQL服务器通信，也可以用JDBC协议与大多数主流数据库服务器通信，其核心功能是分表分库，即将一个大表水平分割为N个小表，存储在后端MySQL服务器里或者其他数据库里。

MyCat发展到目前的版本，已经不是一个单纯的MySQL代理了，它的后端可以支持MySQL、SQL Server、Oracle、DB2、PostgreSQL等主流数据库，也支持MongoDB这种新型NoSQL方式的存储，未来还会支持更多类型的存储。而在最终用户看来，无论是那种存储方式，在MyCat里，都是一个传统的数据库表，支持标准的SQL语句进行数据的操作，这样一来，对前端业务系统来说，可以大幅降低开发难度，提升开发速度

2.传统关系型数据库局限性

传统关系型数据库由于缺乏扩展性在面对大数据时存在巨大的缺陷，但是关系模型、事务机制对于大部分系统又不必不可少，目前业界主流的做法就是将传统数据库进行切分(包括垂直切分、水平切分等)，提高数据库的可扩展性。但是切分之后又带来了新的问题，比如多数据源管理问题、跨节点join问题、分布式事务问题等。下面探讨Mycat如何解决这些问题。

多数据源管理问题

针对多数据源管理问题，主要有两种解决思路，第一:客户端模式，在每个应用程序模块中配置管理自己需要的一个(或者多个)数据源，直接访问各个数据库，在模块内完成数据的整合。第二:通过中间代理层来统一管理所有的数据源，后端数据库集群对前端应用程序透明。第一种方式不具备通用性，每个应用程序都需要自行开发数据整合功能，且对于已经建设完成的系统需要进行代码重构，不适宜推广。目前主要使用的是第二种方式，Mycat 的原理如下: Mycat 的原理中最重要的一个动词是“拦截”，它拦截了用户发送过来的SQL语句，首先对SQL语句做了一些特定的分析:如分片分析、路由分析、读写分离分析、缓存分等，然后将此SQL发往后端的真实数据库，并将返回的结果做适当的处理，最终再返回给用户。

Mycat的原理与其他分布式数据库中间件很类似,但是在架构上还是有区别,Mycat来源于Cobar,但在其基础上进行了很大改进,Mycat的架构如下:

目前主流的分布式数据库中间件还有TDDL、 Amoeba、 Coba等，TDDL不同于其它几款产品，并非独立的中间件，只能算作中间层，是以Jar包方式提供给应用调用。属于JDBC Shard 的思想，网上也有很多其它类似产品。Amoeba是作为一个真正的独立中间件提供服务，即应用去连接Amoeba操作MySQL集群，就像操作单MySQL一样，从架构中可以看来，Amoeba算中间件中的早期产品，后端还在使用JDBC Driver. Cobar 是Amoeba基础上进化的版本，一个显著变化是把后端JDBC Driver改为原生的MySQL通信协议层，这就意味着不能支持Oracle、ProstgreSQL 等主流数据库。MyCat 又是在Cobar基础上发展的版本，后端由BI0改为NIO，并发量有大幅提高，增加了对Order By、GroupBy、limit 等聚合功能的支持，支持目前主流的大部分数据库。

跨节点join问题

Mycat支持inner join、leaf/right join、cross join、 Full join等方式跨节点join,主要是通过全局表，ER分片，Share Join 和catlet(人工智能)四种方式实现:

1、全局表

一个真实的业务系统中，往往存在大量的类似字典表的表格，它们与业务表之间可能有关系，这种关系，可以理解为“标签”，而不应理解为通常的“主从关系”，这些表基本上很少变动，可以根据主键ID进行缓存，下面这张图说明了一个典型的“标签关系”图:

在分片的情况下，当业务表因为规模而进行分片以后，业务表与这些附属的字典表之间的关联，就成了比较棘手的问题，考虑到字典表具有以下几个特性:

• 1.变动不频繁
• 2.数据量总体变化不大
• 3.数据规模不大，很少有超过数十万条记录。

鉴于此，MyCAT定义了一种特殊的表，称之为“全局表”，全局表具有以下特性:

• 1.全局表的插入、更新操作会实时在所有节点上执行，保持各个分片的数据一致性
• 2.全局表的查询操作，只从一个节点获取
• 3.全局表可以跟任何一个表进行J0IN操作

将字典表或者符合字典表特性的一些表定义为全局表，则从另外一个方面，很好的解决了数据J0IN的难题。通过全局表+基于ER关系的分片策略，MyCAT可以满足80%以上的企业应用开发。

全局表配置方式如下(全局表会存储于所以节点) :

总结

以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，谢谢大家对脚本之家的支持。如果你想了解更多相关内容请查看下面相关链接