【开源分布式数据库中间件MyCat介绍】

1、为什么需要MyCat？

虽然云计算时代，传统数据库存在着先天性的弊端，但是NoSQL数据库又无法将其替代。如果传统数据易于扩展，可切分，就可以避免单机（单库）的性能缺陷。MyCat的目标就是：低成本地将现有的单机数据库和应用平滑迁移到“云”端，解决数据存储和业务规模迅速增长情况下的数据瓶颈问题。

 

 

2、何为数据切分？

简单来说，就是指通过某种特定的条件，将我们存放在同一个数据库中的数据分散存放到多个数据库（主机）上面，以达到分散单台设备负载的效果。

数据的切分（Sharding）根据其切分规则的类型，可以分为两种切分模式。一种是按照不同的表（或者Schema）来切分到不同的数据库（主机）之上，这种切可以称之为数据的垂直（纵向）切分；另外一种则是根据表中的数据的逻辑关系，将同一个表中的数据按照某种条件拆分到多台数据库（主机）上面，这种切分称之为数据的水平（横向）切分。

垂直切分的最大特点就是规则简单，实施也更为方便，尤其适合各业务之间的耦合度非常低，相互影响很小，业务逻辑非常清晰的系统。在这种系统中，可以很容易做到将不同业务模块所使用的表分拆到不同的数据库中。根据不同的表来进行拆分，对应用程序的影响也更小，拆分规则也会比较简单清晰。

水平切分于垂直切分相比，相对来说稍微复杂一些。因为要将同一个表中的不同数据拆分到不同的数据库中，对于应用程序来说，拆分规则本身就较根据表名来拆分更为复杂，后期的数据维护也会更为复杂一些。

【分布式最大难点：例如每次从数据库取前10条数据，如果有多个DataNode，那么中央控制节点如果做得不好，那么前后两次查询数据，可能会发生数据不一致性，就像是在随机查询一样，这样分布式也就失去了意义 add by gaojignsong】

 

3、MyCat是什么？

一个彻底开源的，面向企业应用开发的大数据库集群

支持事务、ACID、可以替代MySQL的加强版数据库

一个可以视为MySQL集群的企业级数据库，用来替代昂贵的Oracle集群

一个融合内存缓存技术、NoSQL技术、HDFS大数据的新型SQL Server

结合传统数据库和新型分布式数据仓库的新一代企业级数据库产品

一个新颖的数据库中间件产品

基于阿里开源的Cobar产品而研发，Cobar的稳定性、可靠性、优秀的架构和性能以及众多成熟的使用案例使得MYCAT一开始就拥有一个很好的起点，站在巨人的肩膀上，我们能看到更远。业界优秀的开源项目和创新思路被广泛融入到MYCAT的基因中，使得MYCAT在很多方面都领先于目前其他一些同类的开源项目，甚至超越某些商业产品。

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

MyCat发展到目前的版本，已经不是一个单纯的MySQL代理了，它的后端可以支持MySQL、SQL Server、Oracle、DB2、PostgreSQL等主流数据库，也支持MongoDB这种新型NoSQL方式的存储，未来还会支持更多类型的存储

 

4、MyCat发展史

2013年阿里的Cobar在社区使用过程中发现存在一些比较严重的问题，及其使用限制，经过Mycat发 人第一次改良，第一代改良版——Mycat诞生。 Mycat开源以后，一些Cobar的用户参与了Mycat的 开发，最终Mycat发展成为一个由众多软件公司的实力派架构师和资深开发人员维护的社区型开源软件。

Mycat的前身是OpencloudDB，而现在的Mycat则用来开发一个叫做MycloudOA的云平台的SAAS企业办公软件的，半年的时间里，这个群聚集了一大帮IT人，拥有超过10个“顾问”头衔的、超过十个“架构师”头衔的、超过20个“研发”头衔的庞大志愿者团队，然后，仅有不到3个人提交过文档和少量代码，其他的人都很专业的谈论着需求、谈论着框架、谈论着市场，最后的最后，大家都变成了资深酱油瓶，于是MycloudOA出师未捷身先死。

OpencloudDB改名为Mycat，一个原因是简单好记，另外一个原因，是打算未来入驻Apache。因为Apache Tomcat也是一只猫，从年龄来看，Tomcat算是Mycat表姐吧，从相貌身材来看，Tomcat她表妹，绝对是东方第一萌妹子，虽然目前Rainbow大侠设计的Mycat Logo，看起来是个100%的女汉子。

 

 

5、Cobra不尽如人意的地方

第一个秘密：Cobra会假死

select sleep(500) from company;此SQL会执行等待500秒

 

第二个秘密：高可用的陷阱

Cobra假死的的秘密背后，还隐藏着一个更为“强大”的秘密，那就是假死以后，Cobra的频繁主从切换问题

 

 

第三个秘密：看上去很美的自动切换

Cobar很诱人的一个特性是高可用性，高可用性的原理是数据节点DataNode配置引用两个DataSource，并做心跳检测，当第一个DataSource心跳检测失败后，Cobar自动切换到第二个节点，当第二个节点失败以后，又自动切换回第一个节点，一切看起来很美，无人值守，几乎没有宕机时间。

 

第四个秘密：只实现了一半的NIO

NIO技术用作JAVA服务器编程的技术标准，已经是不容置疑的业界常规做法，若一个Java程序员，没听说过NIO，都不好意思说自己是Java人。所以Cobar采用NIO技术并不意外，但意外的是，只用了一半。

Cobar本质上是一个“数据库路由器”，客户端连接到Cobar，发生SQL语句，Cobar再将SQL语句通过后端与MySQL的通讯接口Socket发出去，然后将结果返回给客户端的Socket中。

 

 

第五个秘密：阻塞、又见阻塞

Cobar本质上类似一个交换机，将后端Mysql 的返回结果数据经过加工后再写入前端连接并返回，于是前后端连接都存在一个“写队列”用作缓冲，后端返回的数据发到前端连接FrontConnection的写队列中排队等待被发送，而通常情况下，后端写入

的的速度要大于前端消费的速度，在跨分片查询的情况下，这个现象更为明显，于是写线程就在这里又一次被阻塞。

解决办法有两个，增大每个前端连接的“写队列”长度，减少阻塞出现的情况，但此办法只是将问题抛给了使用者，要是使用者能够知道这个写队列的默认值小了，然后根据情况进行手动尝试调整也行，但Cobar的代码中并没有把这个问题暴露出来，比如写一个告警日志，队列满了，建议增大队列数。

 

 

 

第六个秘密：又爱又恨的SQL 批处理模式

正如一枚硬币的正反面无法分离，一块磁石怎样切割都有南北极，爱情中也一样，爱与恨总是纠缠着，无法理顺，而Cobar的 SQL 批处理模式，也恰好是这样一个令人又爱又恨的个性。

并发多连接同时执行，则意味着Batch执行速度的提升，这是让人惊喜的一个特性，但单独的数据库连接并发执行，则又带来一个意外的副作用，即事务跨连接了，若一部分事务提交成功，而另一部分失败，则导致脏数据问题

 

 

第七个秘密：庭院深深锁清秋

说起死锁，貌似我们大家都只停留在很久远的回忆中，只在教科书里看到过，也看到过关于死锁产生的原因以及破解方法，只有DBA可能会偶尔碰到数据库死锁的问题。但很多用了Cobar的同学后来经常发现一个奇怪的问题，SQL很久没有应答，百思不得其解，无奈之下找DBA排查后发现竟然有数据库死锁现象，而且比较频繁发生。要搞明白为什么Cobar增加了数据库死锁的概率，只能从源码分析，当一个SQL需要拆分为多条SQL去到多个分片上执行的时候，这个执行过程是并发执行的，即N个SQL同时在N个分片上执行，这个过程抽象为教科书里的事务模型，就变成一个线程需要锁定N个资源并执行操作以后，才结束事务。当这N个资源的锁定顺序是随机的情况下，那么就很容易产生死锁现象，而恰好Cobar并没有保证N个资源的锁定顺序

 

 

 

第八个秘密：出乎意料的连接池

数据库连接池，可能是仅次于线程池的我们所最依赖的“资源池”，其重要性不言而喻，业界也因此而诞生了多个知名的开源数据库连接池。我们知道，对于一个MySQL Server来说，最大连接通常是1000-3000之间，这些连接对于通常的应用足够了，通常每个应用一个Database独占连接，因此足够用了，而到了Cobar的分表分库这里，就出现了问题，因为Cobar对后端MySQL的连接池管理是基于分片——Database来实现的，而不是整个MySQL的连接池共享，以一个分片数为100的表为例，假如50个分片在Server1上，就意味着Server1上的数据库连接被切分为50个连接池，每个池是20个左右的连接，这些连接池并不能互通，于是，在分片表的情况下，我们的并发能力被严重削弱。明明其他水池的水都是满的，你却只能守着空池子等待

 

 

第九个秘密：无奈的热装载

Cobar有一个优点，配置文件热装载，不用重启系统而热装载配置文件，但这里存在几个问题，其中一个问题是很多人不满的，即每次重载都把后端数据库重新断连一次，导致业务中断，而很多时候，大家改配置仅仅是为了修改分片表的定义，规则，增加分片表或者分片定义，而不会改变数据库的配置信息

 

 

第十个秘密：不支持读写分离

不支持读写分离，可能熟悉相关中间件的同学第一反应就是惊讶，因为一个MySQL Proxy最基本的功能就是提供读写分离能力，以提升系统的查询吞吐量和查询性能。但的确Cobar不支持读写分离，而且根据Cobar的配置文件，要实现读写分离，还很麻烦。可能有些人认为，因为无法保证读写分离的时延，因此无法确定是否能查到之前写入的数据，因此读写分离并不重要，但实际上，Mycat的用户里，几乎没有不使用读写分离功能的，后来还有志愿者增加了强制查询语句走主库（写库）的功能，以解决刚才那个问题。

 

 

 

第十一个秘密：不可控的主从切换

Cobar提供了MySQL主从切换能力，这个功能很实用也很方便，但你无法控制它的切换开启或关闭，有时候我们不想它自动切换，因为到目前为止，还没有什么好的方法来确认MySQL写节点宕机的时候，备节点是否已经100%完成数据同步，因此存在数据不一致的风险，如何更可靠的确定是否能安全切换，这个问题比较复杂，Mycat也一直在努力完善这个特性。