一次偶然的機(jī)會(huì)debug代碼瞅了一眼Mysql客戶端的代碼(Java版本)，最引發(fā)我興趣的是這一句：

execSQL是一個(gè)非常重要的方法，所有SQL語句的最終都是交由這個(gè)代碼來實(shí)現(xiàn)的;這個(gè)方法被一個(gè)connectionMutex鎖(這個(gè)鎖其實(shí)就是Connection對(duì)象自己，Mysql客戶端通過使用了“反射”所以不能直接使用this)包裹著這就意味著——在同一時(shí)刻一個(gè)Mysql連接只能執(zhí)行一條SQL語句。

MySQL客戶端的“鎖”

帶著疑問我走讀了這段代碼，畫一幅圖

MysqlIO是負(fù)責(zé)網(wǎng)絡(luò)通訊的底層類，使用的是Java是BIO通訊屬于“標(biāo)準(zhǔn)”的TCP客戶端寫法。它內(nèi)部有三個(gè)重要的成員變量

• mysqlConnection是一個(gè)Socket類型
• mysqlOutput是一個(gè)BufferedOutputStream類型
• InputStream是一個(gè)InputStream類型(Mysql做了一點(diǎn)封裝理解成BufferedInputStream也沒什么問題)

這三個(gè)成員變量的初始化是在MySqlIO的構(gòu)造函數(shù)完成的，當(dāng)執(zhí)行SQL語句的時(shí)相當(dāng)于：

• 鎖住Socket，此時(shí)只有當(dāng)前連接可以使用這個(gè)Socket對(duì)象(實(shí)際的鎖范圍更大)
• mysqlOutput寫入數(shù)據(jù)包，發(fā)送Command(內(nèi)部稱客戶端->服務(wù)器的請(qǐng)求為Command)
• mysqlInput讀取數(shù)據(jù)包，解析返回結(jié)果

如果有多條SQL語句遞交給一個(gè)連接因?yàn)镾ocket被“鎖”所以會(huì)變成串行執(zhí)行。

這不是bug，是特性

帶著疑問我翻看了Mysql的通訊協(xié)議，客戶端->服務(wù)器的標(biāo)準(zhǔn)格式如下：

• 3字節(jié)表示后面“payload”的長(zhǎng)度(所以mysql單數(shù)據(jù)包***值是4M);
• 1字節(jié)表示“sequence_id”;這個(gè)字段似乎沒有什么用途
• ***一個(gè)是變長(zhǎng)的“payload”(長(zhǎng)度由***部分決定)

服務(wù)器端->客戶端(響應(yīng)數(shù)據(jù)包)的標(biāo)準(zhǔn)格式是

• 1字節(jié)表示“類型”
• 根據(jù)不同的類型“payload”會(huì)有不同的變化，比如返回的錯(cuò)誤信息、受影響的行數(shù)等

看到這里我明白原因了。

Mysql的數(shù)據(jù)包中沒有辦法區(qū)分出一個(gè)連接中“不同的數(shù)據(jù)包”。A、B兩條SQL語句，可以通過一個(gè)Socket發(fā)送到服務(wù)器端;服務(wù)器端也會(huì)返回兩個(gè)執(zhí)行結(jié)果。問題是——客戶端如何區(qū)分出哪個(gè)是A的執(zhí)行結(jié)果哪個(gè)是B的執(zhí)行結(jié)果呢?

仔細(xì)觀察上面的數(shù)據(jù)包唯一的方式是sequence_id，A分配一個(gè)id，B分配一個(gè);服務(wù)器端在返回的時(shí)候把相應(yīng)的sequence_id帶回來表示這是某個(gè)SQL語句的執(zhí)行結(jié)果。遺憾的是——sequence_id根本沒用到，服務(wù)器端不會(huì)返回sequence_id信息。(看Mysql的響應(yīng)數(shù)據(jù)包)

正是因?yàn)檫@個(gè)原因?qū)е铝怂械腗ysql客戶端Connection對(duì)象都不是線程安全的。如果想要同時(shí)執(zhí)行多條SQL語句就只能構(gòu)造多個(gè)Connection。

有意思的是MongoDB的協(xié)議格式幾乎和Mysql的一樣，messageLength，requestID，opCode;但是響應(yīng)數(shù)據(jù)包“修正”了這個(gè)bug，messageLength，responseID，opCode。這就意味著mongodb的conneciton是不需要阻塞的而且根本不需要“線程池”。(根據(jù)我觀察connectionsPerHost似乎是沒有用到，難道這個(gè)是為了給大家“安全感”?——我們帶線程池，放心用吧)

更多思考

我想到了更多東西，HTTP 2.0的多路復(fù)用(Multiplexing)。在HTTP1.0中每個(gè)HTTP請(qǐng)求都是一個(gè)TCP請(qǐng)求，瀏覽器載入頁面的時(shí)候會(huì)大量加載css、js、圖片、html短時(shí)間內(nèi)會(huì)發(fā)起大量的TCP請(qǐng)求。在HTTP2.0中同時(shí)向一臺(tái)主機(jī)發(fā)起css、js、圖片可以被承載在同一個(gè)TCP連接中。

AMQP中也有相似的設(shè)計(jì)，叫Channel;一個(gè)TCP連接可以被多個(gè)線程同時(shí)使用。比如用一個(gè)TCP連接可以同時(shí)實(shí)現(xiàn)“訂閱”和“發(fā)布”消息。

微軟RDP協(xié)議中也有相同的設(shè)計(jì)，區(qū)分圖片、聲音、鼠標(biāo)、鍵盤操作(Citrix的ICA設(shè)計(jì)號(hào)稱的32個(gè)通道就是這個(gè)意思)。

SSH協(xié)議中有一個(gè)叫Channel Mechanism的東西，它也是為了實(shí)現(xiàn)“多路復(fù)用”的(這意味著提高了ansible的效率)。

技術(shù)就是這么奇妙，很多東西都是你“借鑒我”，我“借鑒你”。相同的問題相同的解決辦法，如果用心其實(shí)可以匯編成一本書，比如我們上面講的或許就可以叫——“多路復(fù)用的協(xié)議設(shè)計(jì)模式”吧。

【本文是51CTO專欄作者邢森的原創(chuàng)文章，轉(zhuǎn)載請(qǐng)聯(lián)系作者本人獲取授權(quán)】

戳這里，看該作者更多好文