[[400807]]

產(chǎn)出背景

最近這段時間一直忙著集團內(nèi)部安全等保加密相關事項，初步?jīng)Q定使用 shardingsphere 來進行

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

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

老時代的數(shù)據(jù)查詢

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

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

建立數(shù)據(jù)庫連接以及關閉連接屬于耗費時間的事情，如果業(yè)務層每次進行 SQL 查詢都使用此方式，將會產(chǎn)生較大的系統(tǒng)開銷

一般系統(tǒng)的性能要求，單次請求需要穩(wěn)定在 200 ms。經(jīng)過在本地環(huán)境測試，DriverManager 形式創(chuàng)建數(shù)據(jù)庫連接需要 300~500 ms 左右，健身五分鐘，拍照兩小時?

[[400808]]

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

連接池的出現(xiàn)

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

是的，還真有存放數(shù)據(jù)庫連接的池化技術，叫做 連接池。應用程序從連接池中獲取數(shù)據(jù)庫連接，使用過再放到池子里，是不是感覺很 Nice?完美的解決了重復創(chuàng)建消耗資源的情況

看似完美的背后，其實還存在一個致命的問題，那就是最開始去連接池中獲取連接時，連接池中是沒有連接的，還需要走創(chuàng)建流程

連接池是怎么解決這一問題呢?通過創(chuàng)建連接池時初始化其中的連接，一般連接池都有這樣一個參數(shù) initialSize，代表池子中初始化的連接數(shù)量

下圖是 Druid 在執(zhí)行 init 方法時數(shù)據(jù)庫連接初始化的流程，當初始化連接小于池內(nèi)連接時，進行循環(huán)創(chuàng)建，直到池內(nèi)連接滿足初始化數(shù)量

連接池、線程池...這些池化技術的核心思想就是 空間換取時間。因為在絕大數(shù)情況下，空間并沒有那么稀缺，我們更關心的是系統(tǒng)的性能

數(shù)據(jù)源登場

連接池雖然 🐂 🍺 ，但是獨木難支。連接池沒有產(chǎn)生連接的能力，所以還需要配合類似 DriverManager 組件與數(shù)據(jù)庫驅(qū)動配合創(chuàng)建連接。如果這樣放到業(yè)務代碼里，那豈不是還得封裝一層?

這個時候，不約而同的想到一個公司，sun 公司是干啥的?制定規(guī)范的對不對，他們在 jdbc 2.0 版本推出一個 DataSource 的東東，用來進行規(guī)范約束訪問數(shù)據(jù)庫的流程

相當于把 DriverManager 和連接池概念揉合在一起，如果你想獲取數(shù)據(jù)庫連接，你通過我 DataSource 獲取，你不用關心連接池和數(shù)據(jù)庫連接怎么創(chuàng)建的，用就完了，使用完也不用關閉連接。其實，DataSource 獲取的連接來自于連接池，而連接池的連接其實還是從 DriverManager或類似組件中創(chuàng)建的

DriverManager 只是 jdbc 1.0 版本用來調(diào)用數(shù)據(jù)庫驅(qū)動的的工具包，jdbc 2.0 版本推出 DataSource 之后，典型的像 DruidDataSource 就沒有依賴 DriverManager，而是在自己實現(xiàn)類中調(diào)用了數(shù)據(jù)庫驅(qū)動。這里只是重點強調(diào)，數(shù)據(jù)庫連接不一定是使用 DriverManager 創(chuàng)建

總結下，數(shù)據(jù)源(DataSource)是 sun 公司指定用于獲取數(shù)據(jù)庫連接的規(guī)范接口，應用程序于數(shù)據(jù)庫連接抽象的中間層，它存在于 javax.sql 包，用來代替 DriverManager 的方式獲取數(shù)據(jù)庫連接

使用 DataSource 比 DriverManager 到底有什么好處呢

DriverManager

在應用程序里創(chuàng)建/關閉連接時會妨礙應用程序性能

不支持連接池，重復創(chuàng)建/關閉連接，浪費系統(tǒng)性能

DataSource

由于不在應用程序中創(chuàng)建/關閉連接，可以很好的提高應用程序性能

提供了連接池的功能，避免重復創(chuàng)建

這里畫一張圖來描述下，針對應用程序使用 DataSource 和 DriverManager 獲取連接的不同

有了 DataSource 之后，數(shù)據(jù)庫連接、用戶名、密碼都進行了統(tǒng)一的管理，作為 DataSource 屬性的一部分，并且將數(shù)據(jù)庫驅(qū)動名稱填充，底層自動加載

DataSource 技術解析

我們先來看下 DataSource 的接口描述以及對應的方法，先初步進行了解

DataSource 中只有兩個接口，是一個重載的關系，用于建立 DataSource 所代表數(shù)據(jù)源的數(shù)據(jù)庫連接

這里應該注意的是 CommonDataSource 接口，公共數(shù)據(jù)源接口用來定義以下三個數(shù)據(jù)源接口的公共方法

javax.sql.DataSource：定義基礎獲取數(shù)據(jù)庫連接的接口

javax.sql.ConnectionPoolDataSource：定義從數(shù)據(jù)庫連接池中獲取連接的接口

javax.sql.XADataSource：定義獲取分布式事務連接的接口。一般少有直接使用 XA 分布式事務，具體原因參考 分布式 2PC、3PC 事務模型

第一、二種就比較容易理解，sun 公司定義規(guī)范時，就是希望你 普通獲取數(shù)據(jù)庫連接使用 DataSource，數(shù)據(jù)源底層如果是連接池那么使用 ConnectionPoolDataSource

后面發(fā)展逐漸脫離了原本的軌道預期，比如 DruidDataSource 就同時實現(xiàn)了兩者，類圖如下

其實這樣也沒啥事，DruidDataSource 一個類包裝兩種 DataSource 接口實現(xiàn)，這種方式對于使用者是無感知的

完事總結

文章使用循序漸進的方式，幫助大家梳理了一遍 DataSource 產(chǎn)出背景

講述了 jdbc 1.0 版本獲取數(shù)據(jù)庫連接的方式 DriverManager，發(fā)展到 2.0 后的 DataSource，以及其中引入的數(shù)據(jù)庫連接池技術

相信讀者看完對 DataSource 應該有了更深入的了解，感興趣的讀者可以去研讀 Hikari 和 Druid 實現(xiàn)的數(shù)據(jù)源，通過閱讀源碼的方式能夠更好的理解 DataSource 設計思路