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