高性能數據庫連接池的內幕
摘要
如何打造高性能的數據庫連接池框架，可以從哪些角度進行優化，連接池的大量優化實踐如何為你的系統保駕護航，本專題將帶你走進連接池的世界，為你一一揭曉。
大家可能會有這樣疑問：連接池類似于線程池或者對象池，就是一個放連接的池子，使用的時候從里面拿一個，用完了再歸還，功能非常簡單，有什么可講的。
可能還會有這樣的疑問：高性能這么高大上，一個小小的連接池，如何跟高大上靠上邊的。
本主題將會全面介紹連接池原理，高性能的設計，優化實踐，現有連接池的瓶頸及解決方案。同時也會介紹唯品會自研數據庫連接池產品(代號：Caelus)
為什么要有連接池
先看一下連接池所處的位置：
應用框架的業務實現一般都會訪問數據庫，緩存或者HTTP服務。為什么要在訪問的地方加上一個連接池呢?
下面以訪問MySQL為例，執行一個SQL命令，如果不使用連接池，需要經過哪些流程。
1：TCP建立連接的三次握手
2：MySQL認證的三次握手
3：真正的SQL執行
4：MySQL的關閉
5：TCP的四次握手關閉
可以看到，為了執行一條SQL，卻多了非常多我們不關心的網絡交互。
優點：實現簡單。
缺點：
1：網絡IO較多
2：數據庫的負載較高
3：響應時間較長及QPS較低
4：應用頻繁的創建連接和關閉連接，導致臨時對象較多，GC頻繁
5：在關閉連接后，會出現大量TIME_WAIT 的TCP狀態(在2個MSL之后關閉)
使用連接池流程
***次訪問的時候，需要建立連接。 但是之后的訪問，均會復用之前創建的連接。
優點：
1：較少了網絡開銷
2：系統的性能會有一個實質的提升
3：沒了麻煩的TIME_WAIT狀態
當然，現實往往是殘酷的，當我們解決了一個問題的時候，同時伴隨著另外一個問題的產生。
使用連接池面臨的***挑戰： 連接池的性能
連接數和線程數性能優化
分庫DB部署結構：
假設有128個分庫：32個服務器，每個服務器有4個schema。按照128個分庫的設計，便會新建128個獨立數據庫連接池。
數據庫連接池的模型
特點：
1：128個連接池完全獨立，不同的schema也對應不同的連接池
2：先通過拆庫，讀寫等策略選擇對應的連接池，再從連接池獲取一個連接進行操作
3：操作完后，再將連接歸還到對應的連接池中。
優點：
結構簡單，分散競爭
面臨的問題：
1：線程數過多
先看一下新建一個連接池，需要新建的線程數的個數。
連接池
線程數
描述
128個分庫需要的線程數
C3P0
4
3個helperThread (pollerThread)，1個定時任務AdminTaskTimer(DeadlockDetector)
4*128=512
DBCP
1
負責心跳，最小連接數維持，***空閑時間和防連接泄露
1*128=128
Druid
2
一個異步創建連接。一個異步關閉連接。
2*128=256
可以看到隨著分庫的增加，不管選用哪個連接池，線程的個數均會線性增長。線程數過多將會導致內存占用較大: 默認1個線程會占用1M的空間，如果是512個線程，則會占用1M*512=512M上下文切換開銷。
Tips：由于stack和heap申請為虛地址空間，但是一旦使用就不會釋放。(線程也不一定會占用1M的空間)
2：連接數過多
數據庫的連接資源比較重，并且隨著連接的增加，數據庫的性能會有明顯的下降。DBA一般會限制每個DB建立連接的個數，比如限制為3K 。假設數據庫單臺限制3K，32臺則容量為3K*32=96K。如果應用***，最小連接數均為10，則每個應用總計需要128*10=1.28K個連接。那么數據庫理論上支持的應用個數為96K/1.28K= 80 臺
3：不能連接復用
同一個物理機下面不同的schema完全獨立，連接不能復用
優化后的數據庫連接池模型
特點：
1：只有一個連接池,所有節點共享線程 (解決了線程數過多的問題)
2：每個物理機對應一個host, host里面維護多個schema，schema存放連接。
3：同一個host下面的不同schema 可以進行連接復用(解決連接數過多的問題)
獲取連接流程：
1：獲取連接需要帶上 ip,port和schema信息：比如獲取的是host31的schema1
2：先到host31的schema1中獲取空閑連接，但是schema1無空閑連接，便會從schema2中獲取空閑連接。
3：從schema2中獲取的連接執行useschema1，該連接便切換到schema1上面。
4：執行對應的SQL操作，執行完成后，歸還連接到schema1的池子里面。
優點：
1：連接復用：有效減少連接數。
2：提升性能：避免頻繁的新建連接。新建連接的開銷比較大，而使用use schema開銷非常小
3：有效減少線程數。按現有方案大概只需要4個線程即可。而優化前需要512個線程
缺點：
1：管理較為復雜
2：不符合JDBC接口規范。DataSource只有簡單的getConnection()接口，沒有針對獲取對應schema的連接的接口。需要繼承DataSouce，實現特定接口。
事務語句性能優化
優化前執行事務的模型
從連接池里面獲取到連接，默認是自動提交。為了開啟事務，需要執行setautocommit=false 操作，然后再執行具體的SQL，歸還連接的時候，還需要將連接設置為自動提交(需要執行set autocommit=true) 。可以看到開啟事務，需要額外執行兩條事務的語句。
優化后執行事務的模型
每個schema里面所有的連接會按照autocommit進行分組。 分為自動提交(autocommit=true) 和非自動提交(autocommit=false)。獲取連接時優先獲取相同autocommit的分組里的連接，如果沒有可用連接則從另外一個分組中獲取連接，業務操作執行完后，再歸還到對應的分組里面。該種機制避免了開啟事務多執行的兩條事務語句。
鎖性能優化
連接池的通用功能：
連接池主要包含五部分：獲取連接，歸還連接，定時任務，維護組件及資源池
獲取連接：
1：獲取超時：如果超過規定時間未獲取到連接，則會拋出異常
2：有效性檢查：當從資源池里面獲取到資源，需要檢查該資源的有效性，如果失效，再次獲取連接。避免執行業務的時候報錯。
3：創建連接：可以同步創建，也可以異步創建。
歸還連接：
1：歸還連接：比如需要檢查***空閑數，確定是物理關閉還是歸還到連接池
2：銷毀連接: 可同步銷毀也可異步銷毀
定時任務：
1：空閑檢查：主要是檢查空閑連接，連接空閑超過一定時間，則會關閉連接。
2：最小連接數控制：一般會設置最小連接數。保證當前系統里面最小的連接數。如果不夠，則會新建連接。
組件維護：
1：連接狀態控制：空閑，使用，刪除等狀態控制
2：異常處理：對JDBC訪問的異常統一處理，如果異常與連接相關，則會將該連接銷毀掉。
3：緩存：避免對SQL重復解析，PrepareStatement機制下，會對SQL解析的對象進行緩存。
4：JDBC封裝：對JDBC進行了實現，真正的實現是底層的driver,比如MySQL-connector-java 。
資源池：
1：資源池是存放連接的地方，也是連接池最核心的地方。
2：所有的組件基本上都與資源池進行交互，對連接資源的競爭非常激烈。該處的性能將決定了整個連接池的性能。
3：一般資源池的實現是使用JDK提供的BlockingQueue。那么是否有方案可以進行無鎖的設計，來避免競爭。
資源池無鎖設計
獲取連接大概流程：
1：從ThreadLocal里面獲取連接，如果沒有空閑連接，則從全局連接池(CopyOnWriteArrayList)中獲取。
2：如果全局連接池中沒有空閑連接，則會異步新建連接。
3：判定超時時間是否大于閾值，如果小于閾值，則進行自旋。否則進行park休眠。
4：連接建立成功后，會對park的線程進行喚醒
主要從四個方面實現了無鎖的設計：ThreadLocal,CopyOnWriteArrayList，異步建立連接及自旋。
ThreadLocal
1：每個線程均有一個連接隊列。該隊列是全局隊列的引用。
2：獲取連接時先從ThreadLocal里面拿連接，如果連接是空閑狀態，則使用。否則移除掉，再拿下一個，直到拿不到連接為止。
3：歸還連接時，只需要歸還到Threadlocal的隊列里面，同時設置連接為空閑狀態
4：如果使用BlockQueue,獲取連接時調用poll,歸還連接時調用offer，存在兩次鎖的競爭。優化后通過CAS避免了兩次鎖的開銷(獲取連接時，使用CAS置連接為非空閑狀態;歸還時，使用CAS置連接為空閑狀態)
CopyOnWriteArrayList
1：該隊列使用場景是：大量讀，少量寫的操作，并且存儲的數據比較有限。而連接池的場景非常適合采用CopyOnWriteArrayList。
2：在獲取連接或者歸還連接時，只會通過CAS更改連接的狀態，不會對連接池進行添加或者刪除的操作。
3：一般連接池連接的個數比較可控，CopyOnWriteArrayList在寫操作時會對所有連接進行拷貝，對內存影響不大。
異步建立連接
獲取到連接后，判斷一下是否有并發正在等待獲取連接，如果有，則異步建立連接。避免下一個連接的等待。如果CopyOnWriteArrayList沒有空閑連接，則異步建立連接。
自旋
該自旋比較類似于JDK對synchronized的自旋機制。如果發現超時時間大于設定的閾值(比如10微秒)，則會進行線程掛起。如果小于設定的閾值，則重新獲取連接，進行自選，避免線程的上下文切換帶來的性能開銷。。
優化小技巧
方法內聯優化
1：每調用一次方法，線程便會新建一個棧幀，新建棧幀開銷相對比較大
2：JIT在運行時會進行內聯優化，多個方法使用一個棧幀，避免棧幀新建過多
3：JIT方法內聯優化默認的字節碼個數閾值是35個字節，低于35個字節，才會進行優化。(可通過-XX:MaxInlineSize=35進行設置)
通過修改上述代碼，編譯后字節碼修改到34個字節，則可以滿足內聯的條件。
心跳語句選擇
PrepareStatement模式選擇
MySQL driver默認是client模式，如果需要開啟server模式，需要設置 useServerPrepStmts=true 。PrepareStatement默認的client模式和Statement對于DB端沒有區別。大家普遍理解PrepareStatement和Statement的區別是PrepareStatement可以避免SQL注入。但是避免SQL注入是如何做到的?
使用PrepareStatement設置參數的時候，比如調用setString(int parameterIndex, String x)，本地會對設置的參數進行轉義來避免SQL注入。
執行SQL的時候，會將SQL的?替換成轉義后的字符，發送到數據庫執行。
PSCache
MySQLdriver 默認不開啟，可通過設置 cachePrepStmts = true 進行開啟
QueryTimeout
之前也遇到因為開啟了queryTimeout，導致連接泄露的問題。
唯品會自研連接池：Caelus
Caelus是唯品會自研的高性能的分布式的數據庫連接池。
- 高性能：基于無鎖的連接池設計模型來提升連接池性能;
- 在分庫較多的場景下，減少線程數。 假如有128個分庫，現有連接池模型下則需要使用128個獨立的連接池，每個連接池都需要線程(1-4個，不同的連接池不同)處理任務。則總共需要維護128到128*4個線程，開銷巨大。而Caelus連接池會大大減少線程數。
- 連接復用。 對于 一個MySQL 的instance上面有多個schema場景下。現有連接池不同的schema的連接不可復用。而Caelus可以復用不同schema的連接，提升性能。
- 過多的事務指令。如果是事務語句，則從連接池拿到連接后，需要先開啟事務(setautocommit=false)，歸還時需要再設置(set autocommit=true)。每使用一次連接，均需要額外執行兩條事務指令。Caelus能有效減少事務指令。
- 配置規范的統一。結合MySQL的設置，提供規范統一，***的配置。
