研讀：

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，有一個重要提升。

總結

以上是生活随笔為你收集整理的mysql连接池为何不用nio_MyCAT 在 Cobar 的基础上，完成了彻底的 NIO 通讯，并且合并了两个线程池...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。