MyCAT 在 Cobar 的基础上，完成了彻底的 NIO 通讯，并且合并了两个线程池

研读：

1、http://www.mycat.io 《Mycat权威指南》 第 2 章 Mycat 前世今生；

浏览：

深度认识 Sharding-JDBC：做最轻量级的数据库中间层 - 编辑部的故事的个人空间 - 开源中国 https://my.oschina.net/editorial-story/blog/888650

小结：

1、MyCAT 在 Cobar 的基础上，完成了彻底的 NIO 通讯，并且合并了两个线程池

2、MyCAT 解决此问题的方式则更加人性化，首先将原先数组模式的固定长度的队列改为链表模式

3、

Sharding-JDBC只是一个sql翻译器+sql分发+结果聚合；
其功能点是mycat的功能点的真子集；前者不参与连接池管理，而mycat实现了整个mysql级别的连接池共享，而不是Cobar实现的Database级别，另外mycat实现了“SQL->FrontConnection->Cobar->MySQLChanel->MySQL”前后的NIO。

Sharding-JDBC mycat

2.1.1.4 第四个秘密：只实现了一半的 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，有一个重要提升。