MyCat：第二章：Mycat前世今生

《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门，即可获取！

行写操作意味着什么？——可能数据一致性被破坏，谁也不知道那个机器上的数据是最新的。

还有什么情况下，会导致心跳检测失败呢？这是一个不得不说的秘密：当后端数据库达到最大连接后，会对新建连接全部拒绝，

此时，Cobar的心跳检测所建立的新连接也会被拒绝，于是，心跳检测失败，于是，一切都悄悄的发生了。

幸好，大多数同学都没有配置高可用性，或者还不了解此特性，因此，这个秘密，一直在安全的沉睡。

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

Cobar很诱人的一个特性是高可用性，高可用性的原理是数据节点DataNode配置引用两个DataSource，并做心跳检测，当第一

个DataSource心跳检测失败后，Cobar自动切换到第二个节点，当第二个节点失败以后，又自动切换回第一个节点，一切看起来

很美，无人值守，几乎没有宕机时间。

在真实的生产环境中，我们通常会用至少两个Cobar实例组成负载均衡，前端用硬件或者HAProxy这样的负载均衡组件，防止单

点故障，这样一来，即使某个Cobar实例死了，还有另外一台接手，某个Mysql节点死了，切换到备节点继续，至此，一切看起

来依然很美，喝着咖啡，听着音乐，领导视察，你微笑着点头——No problem，Everything is OK!直到有一天，某个Cobar实

例果然如你所愿的死了，不管是假死还是真死，你按照早已做好的应急方案，优雅的做了一个不是很艰难的决定——重启那个故

障节点，然后继续喝着咖啡，听着音乐，轻松写好故障处理报告发给领导，然后又度过了美好的一天。

你忽然被深夜一个电话给惊醒，你来不及发火，因为你的直觉告诉你，这个问题很严重，大量的订单数据发生错误很可能是昨

天重启cobar导致的数据库发生奇怪的问题。你努力排查了几个小时，终于发现，主备两个库都在同时写数据，主备同步失败，

你根本不知道那个库是最新数据，紧急情况下，你做了一个很英明的决定，停止昨天故障的那个cobar实例，然后你花了3个通

宵，解决了数据问题。

这个陷阱的代价太高，不知道有多少同学中枪过，反正我也是躺着中枪过了。若你还不清楚为何会产生这个陷阱，现在我来告

诉你：

1. Cobar启动的时候，会用默认第一个Datasource进行数据读写操作；

2. 当第一个Datasource心跳检测失败，会切换到第二个Datasource；

3. 若有两个以上的Cobar实例做集群，当发生节点切换以后，你若重启其中任何一台Cobar，就完美调入陷阱；

那么，怎么避免这个陷阱？目前只有一个办法，节点切换以后，尽快找个合适的时间，全部集群都同时重启，避免隐患。为何是

重启而不是用节点切换的命令去切换？想象一下32个分片的数据库，要多少次切换？

MyCAT怎么解决这个问题的？很简单，节点切换以后，记录一个properties文件（ conf目录下），重启的时候，读取里面的节

点index，真正实现了无故障无隐患的高可用性。

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

NIO技术用作JAVA服务器编程的技术标准，已经是不容置疑的业界常规做法，若一个Java程序员，没听说过NIO，都不好意思

说自己是Java人。所以Cobar采用NIO技术并不意外，但意外的是，只用了一半。

Cobar本质上是一个“数据库路由器”，客户端连接到Cobar，发生SQL语句，Cobar再将SQL语句通过后端与MySQL的通讯接

口Socket发出去，然后将结果返回给客户端的Socket中。下面给出了SQL执行过程简要逻辑：

SQL->FrontConnection->Cobar->MySQLChanel->MySQL

FrontConnection 实现了NIO通讯，但MySQLChanel则是同步的IO通讯，原因很简单，指令比较复杂，NIO实现有难度，容易

有BUG。后来最新版本Cobar尝试了将后端也NIO化，大概实现了80%的样子，但没有完成，也存在缺陷。

由于前端NIO，后端BIO，于是另一个有趣的设计产生了——两个线程池，前端NIO部分一个线程池，后端BIO部分一个线程

池。各自相互不干扰，但这个设计的结果，导致了线程的浪费，也对性能调优带来很大的困难。

由于后端是BIO，所以，也是Cobar吞吐量无法太高、另外也是其假死的根源。

MyCAT在Cobar的基础上，完成了彻底的NIO通讯，并且合并了两个线程池，这是很大一个提升。从1.1版本开始，MyCAT则

彻底用了JDK7的AIO，有一个重要提升。

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

Cobar本质上类似一个交换机，将后端Mysql 的返回结果数据经过加工后再写入前端连接并返回，于是前后端连接都存在一个

“写队列”用作缓冲，后端返回的数据发到前端连接FrontConnection的写队列中排队等待被发送，而通常情况下，后端写入的

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

解决办法有两个，增大每个前端连接的“写队列”长度，减少阻塞出现的情况，但此办法只是将问题抛给了使用者，要是使用

者能够知道这个写队列的默认值小了，然后根据情况进行手动尝试调整也行，但Cobar的代码中并没有把这个问题暴露出来，比

如写一个告警日志，队列满了，建议增大队列数。于是绝大多数情况下，大家就默默的排队阻塞，无人知晓。

MyCAT解决此问题的方式则更加人性化，首先将原先数组模式的固定长度的队列改为链表模式，无限制，并且并发性更好，此

外，为了让用户知道是否队列过长了（一般是因为SQL结果集返回太多，比如1万条记录），当超过指定阀值（可配）后，会产生

一个告警日志。

1024

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

正如一枚硬币的正反面无法分离，一块磁石怎样切割都有南北极，爱情中也一样，爱与恨总是纠缠着，无法理顺，而Cobar的

SQL 批处理模式，也恰好是这样一个令人又爱又恨的个性。

通常的SQL 批处理，是将一批SQL作为一个处理单元，一次性提交给数据库，数据库顺序处理完以后，再返回处理结果，这个

特性对于数据批量插入来说，性能提升很大，因此也被普遍应用。JDBC的代码通常如下：

String sql = “insert into travelrecord (id,user_id,traveldate,fee,days) values(?,?,?,?,?)”;

ps = con.prepareStatement(sql);

for (Map<String, String> map : list) {

ps.setLong(1, Long.parseLong(map.get(“id”)));

ps.setString(2, (String) map.get(“user_id”));

ps.setString(3, (String) map.get(“traveldate”));

ps.setString(4, (String) map.get(“fee”));

ps.setString(5, (String) map.get(“days”));

ps.addBatch();

}

ps.executeBatch();

con.commit();

ps.clearBatch();

但Cobar的批处理模式的实现，则有几个地方是与传统不同的：

提交到cobar的批处理中的每一条SQL都是单独的数据库连接来执行的

批处理中的SQL并发执行

并发多连接同时执行，则意味着Batch执行速度的提升，这是让人惊喜的一个特性，但单独的数据库连接并发执行，则又带来一

个意外的副作用，即事务跨连接了，若一部分事务提交成功，而另一部分失败，则导致脏数据问题。看到这里，你是该“爱”呢

还是该“恨”？

先不用急着下结论，我们继续看看Cobar的逻辑，SQL并发执行，其实也是依次获取独立连接并执行，因此还是有稍微的时间

差，若某一条失败了，则cobar会在会话中标记”事务失败，需要回滚“，下一个没执行的SQL就抛出异常并跳过执行，客户端

就捕获到异常，并执行rollback，回滚事务。绝大多数情况下，数据库正常运行，此刻没有宕机，因此事务还是完整保证了，但

万一恰好在某个SQL commit指令的时候宕机，于是杯具了，部分事务没有完成，数据没写入。但这个概率有多大呢？一条insert

insert 语句执行commit指令的时间假如是50毫秒，100条同时提交，最长跨越时间是5000毫秒，即5秒中，而这个C指令的时间

占据程序整个插入逻辑的时间的最多20%，假如程序批量插入的执行时间占整个时间的20%（已经很大比例了），那就是

20%×20%=4%的概率，假如机器的可靠性是99.9%，则遇到失败的概率是0.1%×4%=十万分之四。十万分之四，意味着

99.996%的可靠性，亲，可以放心了么？

另外一个问题，即批量执行的SQL，通常都是insert的，插入成功就OK，失败的怎么办？通常会记录日志，重新找机会再插入，

因此建议主键是能日志记录的，用于判断数据是否已经插入。

最后，假如真要多个SQL使用同一个后端MYSQL连接并保持事务怎么办？就采用通常的事务模式，单条执行SQL，这个过程

中，Cobar会采用Session中上次用过的物理连接执行下一个SQL语句，因此，整个过程是与通常的事务模式完全一致。

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

说起死锁，貌似我们大家都只停留在很久远的回忆中，只在教科书里看到过，也看到过关于死锁产生的原因以及破解方法，只有

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也一直在努力完善这个特性。

Mycat闪耀登场

当大批软件工程师开始觉醒，用互联网思维思考和规划自己的人生，第四次工业革命才拉开序幕——《Mycat宣言》

Mycat最早的版本完成于2013年年底，实现于雾霾中的北京城。

Mycat要解决的第一个问题就是要将Cobar后端实现为非阻塞模式。将Cobar从“个人版”提升到真正的“企业版”。据未经证

实的渠道了解，非开源的Cobar内部版本已经实现后端NIO，但是并没有开源出来。于是Mycat注定要诞生了，尽管可能不会是

Leader-us发起的。

但软件界里，总会有那么一些桀骜不驯的人，用一个电脑，在某一个不经意的晚上，写了一段代码，惊艳了这个世界。

Mycat的前身是OpencloudDB，而现在的Mycat QQ群则用来开发一个叫做MycloudOA的云平台的SAAS企业办公软件的，半

年的时间里，这个群聚集了一大帮IT人，拥有超过10个“顾问”头衔的、超过十个“架构师”头衔的、超过20个“研发”头衔的

庞大志愿者团队，然后，仅有不到3个人提交过文档和少量代码，其他的人都很专业的谈论着需求、谈论着框架、谈论着市场，

最后的最后，大家都变成了资深酱油瓶，于是MycloudOA出师未捷身先死。

OpencloudDB改名为Mycat，一个原因是简单好记，另外一个原因，是打算未来入驻Apache。因为Apache Tomcat也是一只

猫，从年龄来看，Tomcat算是Mycat表姐吧，从相貌身材来看，Tomcat她表妹，绝对是东方第一萌妹子，虽然目前Rainbow大

侠设计的Mycat Logo，看起来是个100%的女汉子。

Mycat 1.0的发布，立即引起不少人的关注，曾经参与MycloudOA开发的一些小伙伴陆续加入进来，资深酱油师Michael还注册

了一个openclouddb的网站，随后又实现了Mycat全局序列号（基于文件方式）；一些了解或使用过Cobar的同学也陆续加入，

网名为无影的大侠，提供了最早的Mycat分页排序的源码，最早在生产系统上部署了Mycat并且采用HA Proxy方式做高可用方

案；随后，一个叫做小鱼的PHP高手，在不到3个月时间内，用Mycat改造了原先的电商系统。后来又有一些美容美发的SAAS创

业项目采用了Mycat；再后来，一些比较大的电信软件领域的公司和项目开始使用Mycat，他们中的大多数都对Mycat做过不少

的贡献，比如测试，Bug修复等。发展到今天，Mycat核心研发团队里的大多数人，都是来自上述这些公司。

Mycat １.3的诞生，是Mycat历史上最重大的一个里程碑。在这个版本里，需求、测试和功能开发各项工作，首次从个人为主

变为开源团队为主的模式，更多的人参与到需求、开发、测试以及Bug修复活动中，基本上确定的Bug都在２４小时内修复并有

志愿者或用户确认修复。Mycat 1.3版本的性能与1.2比提升巨大，功能更完备，这是因为包括武、成都-研发、冰峰影、

Leader-us等实力派编程高手各自负责一部分重要模块并一起协同研发，后来又加入聆听、从零开始、南哥、Mclaren、兵临城

下等新的一批实力派编程达人，以及正在排队等待收编的PCY实力派干将，其他关于参与Mycat官网建设、文档编写和翻译的就

更多了（当然也失联很多）。截至目前，Mycat志愿者团队有以Marshy大美女为首的负责官网和广告的团队，以Leader-us为首

的负责Mycat-Server研发的团队、以Rainbow为首的Mycat-Web的研发团队、以海王星为首的QA团队，以及群龙无首的测试

团队和DBA团队。

此外，Mycat开源社区正在进一步强化数据库监控、智能调优等方面的功能，未来将实现一键优化的能力，根据拦截到的SQL的

执行统计数据，自动分析热点数据、给出建议的索引和优化措施以及读写分离的建议，DBA一键完成优化，数据迁移也将可以在
节目上点击鼠标完成。
Mycat截至到2015年4月，保守估计已经有超过60个项目在使用，主要应用在电信领域、互联网项目，大部分是交易和管理系
统，少量是信息系统。比较大的系统中，数据规模单表单月30亿。以后Mycat和Mycat社区成为IT和互联网创业的最佳伴侣。
下面信息是使用者在Mycat github上公布的使用案例：
更多案例请点击：
https://github.com/MyCATApache/Mycat-Server/issues/112

线程、数据库、算法、JVM、分布式、微服务、框架、Spring相关知识

一线互联网P7面试集锦+各种大厂面试集锦

学习笔记以及面试真题解析

《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门，即可获取！
、JVM、分布式、微服务、框架、Spring相关知识

[外链图片转存中…(img-oIuRCitq-1714709406764)]

一线互联网P7面试集锦+各种大厂面试集锦

[外链图片转存中…(img-msS5wNzS-1714709406765)]

学习笔记以及面试真题解析

[外链图片转存中…(img-jpsDD8We-1714709406765)]

《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门，即可获取！