[[400807]]

產出背景

最近這段時間一直忙著集團內部安全等保加密相關事項，初步決定使用 shardingsphere 來進行

因為項目眾多，需要兼容的需求也隨之而來，加密數據源和動態數據源的互相兼容，以及分庫分表和加密數據源的兼容等等，反正一言不合就兼容

無疑，上面這些或多或少都和數據源有關系，所以在處理不同兼容性等問題時，也讓我再次對 DataSource 產生了了解的興趣，這個曾經被很多人遺忘的重要概念

老時代的數據查詢

在很久很久以前(反正忘了多久)，那個時候應用程序連接數據庫還是這么個操作

可以清楚的看到，曾經獲取數據庫連接的代碼還需要使用 DriverManager，大家都清楚，DriverManager#getConnection 是通過數據庫驅動直接與數據庫建立連接

建立數據庫連接以及關閉連接屬于耗費時間的事情，如果業務層每次進行 SQL 查詢都使用此方式，將會產生較大的系統開銷

一般系統的性能要求，單次請求需要穩定在 200 ms。經過在本地環境測試，DriverManager 形式創建數據庫連接需要 300~500 ms 左右，健身五分鐘，拍照兩小時?

[[400808]]

隨著系統的發展迭代，出于 系統的復雜度以及對性能的要求，這種獲取連接的方式是難以接受的

連接池的出現

相信有些讀者能夠聯想出來，數據庫連接創建消耗資源這個場景好像在哪聽過，沒錯，和線程創建的情況基本類似。既然線程可以用線程池關聯，那數據庫連接是不是可以放到一個池子中?

是的，還真有存放數據庫連接的池化技術，叫做 連接池。應用程序從連接池中獲取數據庫連接，使用過再放到池子里，是不是感覺很 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 設計思路