代碼不多，文章不長，簡要描述了下 DataSource 演程序序的故事
文章產出背景
最近這段時間一直忙著集團內部安全等保加密相關事項，初步決定使用 shardingsphere 來進行
因為專案眾多，需要兼容的需求也隨之而來，加密資料源和動態資料源的互相兼容，以及分庫分表和加密資料源的兼容等等，反正一言不合就兼容
無疑，上面這些或多或少都和資料源有關系，所以在處理不同兼容性等問題時，也讓我再次對 DataSource 產生了了解的興趣，這個曾經被很多人遺忘的重要概念
老時代的資料查詢
在很久很久以前（反正忘了多久），那個時候程式員連接資料庫還是這么個操作
可以清楚的看到，曾經獲取資料庫連接的代碼還需要使用 DriverManager，大家都清楚，DriverManager#getConnection 是通過資料庫驅動直接與資料庫建立連接
而建立資料庫連接屬于耗費時間的事情，如果業務層每次進行 SQL 查詢都使用此方式，將會產生較大的系統開銷
一般系統的性能要求，單次請求需要穩定在 200 ms，經過在本地環境測驗，DriverManager 形式創建資料庫連接需要 300~500 ms 左右，健身五分鐘，拍照兩小時？
隨著系統的發展迭代，出于 系統的復雜度以及對性能的要求，這種獲取連接的方式是難以接受的
連接池的出現
相信有些讀者能夠聯想出來，資料庫連接創建消耗資源這個場景好像在哪聽過，沒錯，和執行緒創建的情況基本類似，既然執行緒可以用執行緒池關聯，那資料庫連接是不是可以放到一個池子中？
是的，還真有存放資料庫連接的池化技術，叫做 連接池，應用程式從連接池中獲取資料庫連接，使用過再放到池子里，是不是感覺很 Nice？完美的解決了重復創建消耗資源的情況
看似完美的背后，其實還存在一個致命的問題，那就是最開始去連接池中獲取連接時，連接池中是沒有連接的，還需要走創建流程
連接池是怎么解決這一問題呢？通過創建連接池時初始化其中的連接，一般連接池都有這樣一個引數 initialSize，代表池子中初始化的連接數量
下圖是 Druid 在執行 init 方法時資料庫連接初始化的流程，當初始化連接小于池內連接時，進行回圈創建，直到池內連接滿足初始化數量
連接池、執行緒池…這些池化技術的核心思想就是 空間換取時間，因為在絕大數情況下，空間并沒有那么稀缺，我們更關心的是系統的性能
資料源登場
連接池雖然 🐂 🍺 ，但是獨木難支，連接池沒有產生連接的能力，所以還需要配合類似 DriverManager 組件與資料庫驅動配合創建連接，如果這樣放到業務代碼里，那豈不是還得封裝一層？
這個時候，不約而同的想到一個公司，sun 公司是干啥的？制定規范的對不對，他們在 jdbc 2.0 版本推出一個 DataSource 的東東，用來進行規范約束
相當于把 DriverManager 和連接池概念揉合在一起，如果你想獲取資料庫連接，你通過我 DataSource 獲取，你不用關心連接池和資料庫連接怎么創建的，用就完了，其實，DataSource 獲取的連接來自于連接池，而連接池的連接其實還是從 DriverManager或類似組件中創建的
DriverManager 只是 jdbc 1.0 版本用來呼叫資料庫驅動的的工具包，jdbc 2.0 版本推出 DataSource 之后，典型的像 DruidDataSource 就沒有依賴 DriverManager，而是在自己實作類中呼叫了資料庫驅動，這里只是重點強調，資料庫連接不一定是使用 DriverManager 創建
總結下，資料源（DataSource）是 sun 公司指定用于獲取資料庫連接的規范介面，應用程式于資料庫連接抽象的中間層，它存在于 javax.sql 包，用來代替 DriverManager 的方式獲取資料庫連接
使用 DataSource 比 DriverManager 到底有什么好處呢
DriverManager
-
在應用程式里創建/關閉連接時會妨礙應用程式性能
-
不支持連接池，重復創建/關閉連接，浪費系統性能
DataSource
-
由于不在應用程式中創建/關閉連接，可以很好的提高應用程式性能
-
提供了連接池的功能，避免重復創建
這里畫一張圖來描述下，針對應用程式使用 DataSource 和 DriverManager 獲取連接的不同
有了 DataSource 之后，資料庫連接、用戶名、密碼都進行了統一的管理，作為 DataSource 屬性的一部分，并且將資料庫驅動名稱填充，底層自動加載
DataSource 技術決議
我們先來看下 DataSource 的介面描述以及對應的方法，先初步進行了解
DataSource 中只有兩個介面，是一個多載的關系，用于建立 DataSource 所代表資料源的資料庫連接
這里應該注意的是 CommonDataSource 介面，公共資料源介面用來定義以下三個資料源介面的公共方法
-
javax.sql.DataSource：定義基礎獲取資料庫連接的介面
-
javax.sql.ConnectionPoolDataSource：定義從資料庫連接池中獲取連接的介面
-
javax.sql.XADataSource：定義獲取分布式事務連接的介面，一般少有直接使用 XA 分布式事務，具體原因參考 分布式 2PC、3PC 事務模型
第一、二種就比較容易理解，sun 公司定義規范時，就是希望你 普通獲取資料庫連接使用 DataSource，資料源底層如果是連接池那么使用 ConnectionPoolDataSource
后面發展逐漸脫離了原本的軌道預期，比如 DruidDataSource 就同時實作了兩者，類圖如下
其實這樣也沒啥事，DruidDataSource 一個類包裝兩種 DataSource 介面實作，這種方式對于使用者是無感知的
完事總結
文章使用循序漸進的方式，幫助大家梳理了一遍 DataSource 產出背景
講述了 jdbc 1.0 版本獲取資料庫連接的方式 DriverManager，發展到 2.0 后的 DataSource，以及其中引入的資料庫連接池技術
相信讀者看完對 DataSource 應該有了更深入的了解，感興趣的讀者可以去研讀 Hikari 和 Druid 實作的資料源，通過閱讀原始碼的方式能夠更好的理解 DataSource 設計思路
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/299619.html
標籤：其他
上一篇：程式員童子功之計算機網路知識