研讀：

1、http://www.mycat.io 《Mycat權(quán)威指南》?第 2 章 Mycat 前世今生；

瀏覽：

深度認(rèn)識 Sharding-JDBC：做最輕量級的數(shù)據(jù)庫中間層 - 編輯部的故事的個人空間 - 開源中國 https://my.oschina.net/editorial-story/blog/888650

小結(jié)：

1、MyCAT 在 Cobar 的基礎(chǔ)上，完成了徹底的 NIO 通訊，并且合并了兩個線程池

2、MyCAT 解決此問題的方式則更加人性化，首先將原先數(shù)組模式的固定長度的隊列改為鏈表模式

3、

Sharding-JDBC只是一個sql翻譯器+sql分發(fā)+結(jié)果聚合；

其功能點是mycat的功能點的真子集；前者不參與連接池管理，而mycat實現(xiàn)了整個mysql級別的連接池共享，而不是Cobar實現(xiàn)的Database級別，另外mycat實現(xiàn)了“SQL->FrontConnection->Cobar->MySQLChanel->MySQL”前后的NIO。

Sharding-JDBC mycat

2.1.1.4 第四個秘密：只實現(xiàn)了一半的 NIO

NIO 技術(shù)用作 JAVA 服務(wù)器編程的技術(shù)標(biāo)準(zhǔn)，已經(jīng)是不容置疑的業(yè)界常規(guī)做法，若一個 Java 程序員，沒聽

說過 NIO，都不好意思說自己是 Java 人。所以 Cobar 采用 NIO 技術(shù)并不意外，但意外的是，只用了一半。

Cobar 本質(zhì)上是一個“數(shù)據(jù)庫路由器”，客戶端連接到 Cobar，發(fā)生 SQL 語句，Cobar 再將 SQL 語句通過

后端與 MySQL 的通訊接口 Socket 發(fā)出去，然后將結(jié)果返回給客戶端的 Socket 中。下面給出了 SQL 執(zhí)行過程簡

要邏輯：

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

FrontConnection 實現(xiàn)了 NIO 通訊，但 MySQLChanel 則是同步的 IO 通訊，原因很簡單，指令比較復(fù)

雜，NIO 實現(xiàn)有難度，容易有 BUG。后來最新版本 Cobar 嘗試了將后端也 NIO 化，大概實現(xiàn)了 80%的樣子，但

沒有完成，也存在缺陷。

由于前端 NIO，后端 BIO，于是另一個有趣的設(shè)計產(chǎn)生了——兩個線程池，前端 NIO 部分一個線程池，后

端 BIO 部分一個線程池。各自相互不干擾，但這個設(shè)計的結(jié)果，導(dǎo)致了線程的浪費，也對性能調(diào)優(yōu)帶來很大的困

難。

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

MyCAT 在 Cobar 的基礎(chǔ)上，完成了徹底的 NIO 通訊，并且合并了兩個線程池，這是很大一個提升。從 1.1

版本開始，MyCAT 則徹底用了 JDK7 的 AIO，有一個重要提升。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。