如何理解高性能數(shù)據(jù)庫連接池

本篇文章為大家展示了如何理解高性能數(shù)據(jù)庫連接池，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

為什么要有連接池

先看一下連接池所處的位置：

應用框架的業(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)的性能會有一個實質的提升

3：沒了麻煩的TIME_WAIT狀態(tài)

當然，現(xià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ù)過多將會導致內存占用較大:  默認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,獲取連接時調用poll,歸還連接時調用offer，存在兩次鎖的競爭。優(yōu)化后通過CAS避免了兩次鎖的開銷(獲取連接時，使用CAS置連接為非空閑狀態(tài);歸還時，使用CAS置連接為空閑狀態(tài))

CopyOnWriteArrayList

1：該隊列使用場景是：大量讀，少量寫的操作，并且存儲的數(shù)據(jù)比較有限。而連接池的場景非常適合采用CopyOnWriteArrayList。

2：在獲取連接或者歸還連接時，只會通過CAS更改連接的狀態(tài)，不會對連接池進行添加或者刪除的操作。

3：一般連接池連接的個數(shù)比較可控，CopyOnWriteArrayList在寫操作時會對所有連接進行拷貝，對內存影響不大。

異步建立連接

獲取到連接后，判斷一下是否有并發(fā)正在等待獲取連接，如果有，則異步建立連接。避免下一個連接的等待。如果CopyOnWriteArrayList沒有空閑連接，則異步建立連接。

自旋

該自旋比較類似于JDK對synchronized的自旋機制。如果發(fā)現(xiàn)超時時間大于設定的閾值(比如10微秒)，則會進行線程掛起。如果小于設定的閾值，則重新獲取連接，進行自選，避免線程的上下文切換帶來的性能開銷。。

優(yōu)化小技巧

方法內聯(lián)優(yōu)化

1：每調用一次方法，線程便會新建一個棧幀，新建棧幀開銷相對比較大

2：JIT在運行時會進行內聯(lián)優(yōu)化，多個方法使用一個棧幀，避免棧幀新建過多

3：JIT方法內聯(lián)優(yōu)化默認的字節(jié)碼個數(shù)閾值是35個字節(jié)，低于35個字節(jié)，才會進行優(yōu)化。(可通過-XX:MaxInlineSize=35進行設置)

通過修改上述代碼，編譯后字節(jié)碼修改到34個字節(jié)，則可以滿足內聯(lián)的條件。

心跳語句選擇

PrepareStatement模式選擇

MySQL driver默認是client模式，如果需要開啟server模式，需要設置 useServerPrepStmts=true  。PrepareStatement默認的client模式和Statement對于DB端沒有區(qū)別。大家普遍理解PrepareStatement和Statement的區(qū)別是PrepareStatement可以避免SQL注入。但是避免SQL注入是如何做到的?

使用PrepareStatement設置參數(shù)的時候，比如調用setString(int parameterIndex, String  x)，本地會對設置的參數(shù)進行轉義來避免SQL注入。

執(zhí)行SQL的時候，會將SQL的?替換成轉義后的字符，發(fā)送到數(shù)據(jù)庫執(zhí)行。

PSCache

MySQLdriver 默認不開啟，可通過設置 cachePrepStmts = true 進行開啟

QueryTimeout

之前也遇到因為開啟了queryTimeout，導致連接泄露的問題。

唯品會自研連接池：Caelus

Caelus是唯品會自研的高性能的分布式的數(shù)據(jù)庫連接池。

1. 高性能：基于無鎖的連接池設計模型來提升連接池性能;

2. 在分庫較多的場景下，減少線程數(shù)。  假如有128個分庫，現(xiàn)有連接池模型下則需要使用128個獨立的連接池，每個連接池都需要線程(1-4個，不同的連接池不同)處理任務。則總共需要維護128到128*4個線程，開銷巨大。而Caelus連接池會大大減少線程數(shù)。

3. 連接復用。 對于 一個MySQL  的instance上面有多個schema場景下?，F(xiàn)有連接池不同的schema的連接不可復用。而Caelus可以復用不同schema的連接，提升性能。

4. 過多的事務指令。如果是事務語句，則從連接池拿到連接后，需要先開啟事務(setautocommit=false)，歸還時需要再設置(set  autocommit=true)。每使用一次連接，均需要額外執(zhí)行兩條事務指令。Caelus能有效減少事務指令。

5. 配置規(guī)范的統(tǒng)一。結合MySQL的設置，提供規(guī)范統(tǒng)一，合理的配置。 

上述內容就是如何理解高性能數(shù)據(jù)庫連接池，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業(yè)資訊頻道。