面試官:爲什麼數據庫連接池不採用 IO 多路複用?我懵逼了。。

來源:zhihu.com/question/23084473

今天我們聊一個不常見的 Java 面試題:爲什麼數據庫連接池不採用 IO 多路複用?

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

首先糾正一個常見的誤解。IO多路複用聽上去好像是多個數據可以共享一個IO(socket連接),實際上並非如此。「IO多路複用不是指多個服務共享一個連接,而僅僅是指多個連接的管理可以在同一進程」。在網絡服務中,IO多路複用起的作用是「一次性把多個連接的事件通知業務代碼處理」。至於這些事件的處理方式,到底是業務代碼循環着處理、丟到隊列裏,還是交給線程池處理,由業務代碼決定。

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

爲什麼併發查詢一定要使用多個連接才能完成呢?因爲DB一般是使用連接作爲Session管理的基本單元。在一個連接中,SQL語句的執行必須是串行、同步的。這是由於對於每一個Session,DB都要維護一組狀態來支持查詢,比如事務隔離級別,當前Session的變量等。只有單Session內串行執行,才能維護查詢的正確性(試想一下一組sql在不斷的增減變量,然後這組sql亂序執行會發生什麼)。維護這些狀態需要耗費內存,同時也會消耗CPU和磁盤IO。這樣,限制對DB的連接數,就是在限制對DB資源的消耗。

因此,對DB來說,關鍵是要限制連接的數目。這個要求無論是DB連接池還是NIO的連接管理都能做到。

這樣問題就繞回來了,爲什麼DB連接不能放到IO多路複用裏一併執行嗎?爲啥大家都用連接池?

答案是,可以用IO多路複用——但是「使用JDBC不行」。JDBC是一個出現了近20年的標準,它的設計核心是BIO(因爲199X年時還沒有別的IO可以用):調用者在通過JDBC時執行比如query這樣的API,在沒有執行完成之前,整個調用線程被卡住。而類似於Mysql Connector/J這樣的driver完備的實現了這套語義。

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

  1. 將IO模式調整爲Non-Blocking,這樣就可以掛到IO多路複用的內核上(select、epoll、kqueue……)
  2. 在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,用戶名密碼和連接池的容量參數,就可以做到自行管理連接。

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

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

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

近期熱文推薦:

1.1,000+ 道 Java面試題及答案整理(2022最新版)

2.勁爆!Java 協程要來了。。。

3.Spring Boot 2.x 教程,太全了!

4.別再寫滿屏的爆爆爆炸類了,試試裝飾器模式,這纔是優雅的方式!!

5.《Java開發手冊(嵩山版)》最新發布,速速下載!

覺得不錯,別忘了隨手點贊+轉發哦!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章