淺談數據庫連接池爲何不採用 IO 多路複用？

前言

這是一個非常好的問題。IO 多路複用被視爲是非常好的性能助力器。但是一般我們在使用 DB 時，還是經常性採用 c3p0，tomcat connection pool 等技術來與 DB 連接，哪怕整個程序已經變成以 Netty 爲核心。這到底是爲什麼？

常見的誤解

IO 多路複用聽上去好像是多個數據可以共享一個 IO（socket 連接），實際上並非如此。「IO 多路複用不是指多個服務共享一個連接，而僅僅是指多個連接的管理可以在同一進程」。

在網絡服務中，IO 多路複用起的作用是**「一次性把多個連接的事件通知業務代碼處理」**。至於這些事件的處理方式，到底是業務代碼循環着處理、丟到隊列裏，還是交給線程池處理，由業務代碼決定。

對於使用 DB 的程序來講，不管使用多路複用，還是連接池，都要維護一組網絡連接，支持併發的查詢。

爲什麼 DB 連接不能放到 IO 多路複用裏一併執行嗎？

答案是，可以用 IO 多路複用——但是**「使用 JDBC 不行」**。

JDBC 是一個出現了近 20 年的標準，它的設計核心是 BIO（因爲 199X 年時還沒有別的 IO 可以用）：調用者在通過 JDBC 時執行比如 query 這樣的 API，在沒有執行完成之前，整個調用線程被卡住。而類似於 Mysql Connector/J 這樣的 driver 完備的實現了這套語義。

當然如果 DB Client 的協議的連接處理和解析稍微改一下：

• 將 IO 模式調整爲 Non-Blocking，這樣就可以掛到 IO 多路複用的內核上（select、epoll、kqueue……）

• 在 Non-Blocking 實現的基礎之上實現數據庫協議的編碼和解析

就可以實現用 IO 多路複用來訪問 DB。

實際上很多其他語言 / 框架裏都是這麼幹的。比如

• Nodejs

see https://github.com/sidorares/node-mysql2；

• Vert.X 的 db 客戶端

https://github.com/mauricio/postgresql-async，不要在意這個名字，它實際上同時支持 mysql 和 postgres。只不過對於 IO 多路複用，數據庫官方似乎都沒做這種支持——他們只支持 JDBC、ODBC 等等這些標準協議。

那麼爲什麼基於 IO 多路複用的實現不能成爲默認的?

對於數據庫開發者來說。這種用法在整體的用戶裏佔有量非常小，所以也許不值當的花大力氣。只需要把協議寫清楚就可以做實現。

（比如 https://dev.mysql.com/doc/internals/en/client-server-protocol.html）那麼社區的有興趣的人自然就可以去做。

另外一個原因是體系的支持。簡單來講，如果沒有一個大的 Reactive 的運行環境，IO 多路複用的使用會非常受限。

IO 多路複用之所以能成立，是需要**「整個程序要有一個 IO 多路複用的驅動代碼」**——就是 select 那句調用——等待事件來臨，一個 blocking 的 API。整個程序必須以這個驅動代碼爲核心。這樣就對整個代碼的結構產生重大的影響。這種影響是沒法用簡單的接口抽象的。

Java Web 容器之所以可以使用 NIO 是因爲 NIO 可以被封裝到容器內部。Web 容器對外暴露的還是傳統的多線程形式的 Java EE 接口。

如果 DB 和 Web 容器同時使用 NIO，那麼調用的 DB 連接庫與必須與容器有一個約定描述**「DB 的連接管理如何接入 Web 容器的 NIO 的驅動代碼」**。在 Java 這個大環境下，不同人，不同的容器寫的代碼不同；又或者，不使用任何常見的容器，而是自己用 NIO 去封裝一個。這樣是無法形成代碼上的約定的。那麼多個獨立的組件就不能很好的共享 NIO 的驅動代碼。

上面這個用法假設整個程序應該共享一個 NIO 驅動代碼。

那麼 Web 和 DB 可不可以各用各的呢？

也是可以的，但是爲了保證這兩個 NIO 驅動代碼不會相互 block，最好要分開兩個線程。這樣一來就會打破一般 Web 服務一個請求處理用一個線程的一般做法，會讓程序邊的更復雜——你的業務代碼和 DB 查詢之間必須做跨線程數據交換。

相反，連接池的實現就相對獨立的多，也簡單的多。外界只要配好 DB URL，用戶名密碼和連接池的容量參數，就可以做到自行管理連接。

而 Nodejs 和 Vert.X 是完全不同的。他們本質就是 Reactive 的。他們的 NIO 的驅動方式是其運行時的基礎——所有要在這個基礎上開發的代碼都必須遵守同樣的 NIO + 異步開發規範，使用同一個 NIO 的驅動。這樣 DB 與 NIO 的協作就不成問題了。

那麼爲什麼基於 IO 多路複用的實現不能成爲默認的?

批處理數據分析代碼都是這樣的場景。這樣的程序寫成 NIO 就會得不償失——代碼不容易懂，也沒有任何效率上的優勢。類似於 Nodejs 這樣的運行時在此場景下，反而要利用 async 或等價的語法來讓代碼看起來是同步的，這樣才容易寫。

總結

DB 訪問一般採用連接池這種現象是生態造成的。歷史上的 BIO + 連接池的做法經過多年的發展，已經解決了主要的問題。在 Java 的大環境下，這個方案是非常靠譜的，成熟的。而基於 IO 多路複用的方式儘管在性能上可能有優勢，但是其對整個程序的代碼結構要求過多，過於複雜。當然，如果有特定的需要，希望使用 IO 多路複用管理 DB 連接，是完全可行的。

作者：大寬寬

來源：www.zhihu.com/question/23084473

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/TIEOrrq8pYIoyzmOSvNOQA