數(shù)據(jù)庫(kù)連接池

幾乎所有的商業(yè)應(yīng)用都有大量數(shù)據(jù)庫(kù)訪問(wèn)，通常這些應(yīng)用會(huì)采用數(shù)據(jù)庫(kù)連接池。理解為什么需要連接池，連接池的實(shí)現(xiàn)原理，系統(tǒng)架構(gòu)和性能目標(biāo)對(duì)于寫出正確、高效的程序很有幫助。這些概念可用于系統(tǒng)運(yùn)行參數(shù)的配置，同時(shí)對(duì)于理解并發(fā)和分布式處理也很有幫助。

通用一點(diǎn)來(lái)說(shuō)，一個(gè)有經(jīng)驗(yàn)的工程師面對(duì)任何問(wèn)題都會(huì)試著回答三個(gè)問(wèn)題：為什么，是什么，怎么做。了解為什么可以明白問(wèn)題的真正目的，有助于開放思路和避免無(wú)用功。是什么則回答問(wèn)題的本質(zhì)概念，是正確答案的保障。怎么做則給出可重復(fù)的問(wèn)題解決思路，使得問(wèn)題總是以正確、高效的方式得到解決。本篇文章按這個(gè)思路來(lái)解決數(shù)據(jù)庫(kù)連接池如何配置的問(wèn)題。

1 為什么需要連接池

任何數(shù)據(jù)庫(kù)的訪問(wèn)都需要首先建立數(shù)據(jù)庫(kù)連接。這是一個(gè)復(fù)雜、緩慢的處理。牽涉到通信建立（包括 TCP 的三次握手）、認(rèn)證、授權(quán)、資源的初始化和分配等一系列任務(wù)。而且數(shù)據(jù)庫(kù)服務(wù)器通常和應(yīng)用服務(wù)器是分開的，所有的操作都是分布式網(wǎng)絡(luò)請(qǐng)求和處理。建立數(shù)據(jù)庫(kù)連接時(shí)間通常在 100ms 或更長(zhǎng)。而通常小數(shù)據(jù)的 CRUD 數(shù)據(jù)庫(kù)操作是 ms 級(jí)或更短，加上網(wǎng)絡(luò)延遲一般 10 到 50 個(gè) ms 就可以完成多數(shù)數(shù)據(jù)庫(kù)處理結(jié)果。在應(yīng)用啟動(dòng)時(shí)預(yù)先建立一些數(shù)據(jù)庫(kù)連接，應(yīng)用程序使用已有的連接可以極大提高響應(yīng)速度。另外，Web 服務(wù)應(yīng)用當(dāng)客戶很多時(shí)，有很多線程，連接數(shù)目過(guò)多以及頻繁創(chuàng)建/刪除連接也會(huì)影響數(shù)據(jù)庫(kù)的性能。

總結(jié)起來(lái)，采用數(shù)據(jù)庫(kù)連接有如下好處：

• 節(jié)省了創(chuàng)建數(shù)據(jù)庫(kù)連接的時(shí)間，通常這個(gè)時(shí)間大大超過(guò)處理數(shù)據(jù)訪問(wèn)請(qǐng)求的時(shí)間。
• 統(tǒng)一管理數(shù)據(jù)庫(kù)請(qǐng)求連接，避免了過(guò)多連接或頻繁創(chuàng)建/刪除連接帶來(lái)的性能問(wèn)題。
• 監(jiān)控了數(shù)據(jù)庫(kù)連接的運(yùn)行狀態(tài)和錯(cuò)誤報(bào)告，減少了應(yīng)用服務(wù)的這部分代碼。
• 可以檢查和報(bào)告不關(guān)閉數(shù)據(jù)庫(kù)連接的錯(cuò)誤，幫助運(yùn)維監(jiān)測(cè)數(shù)據(jù)庫(kù)訪問(wèn)阻塞和幫助程序員寫出正確數(shù)據(jù)庫(kù)訪問(wèn)代碼。

2 數(shù)據(jù)庫(kù)連接池是什么

2.1 實(shí)現(xiàn)原理

如同多數(shù)分布式基礎(chǔ)構(gòu)件，連接池的原理比較簡(jiǎn)單，但是牽涉到數(shù)據(jù)庫(kù)，操作系統(tǒng)，編程語(yǔ)言，運(yùn)維以及應(yīng)用場(chǎng)景的不同特點(diǎn)，具體實(shí)現(xiàn)比較復(fù)雜。從數(shù)據(jù)庫(kù)誕生就有的廣泛需求，半個(gè)世紀(jì)后還有不斷改進(jìn)提高的余地。

原理上，在應(yīng)用開始時(shí)創(chuàng)建一組數(shù)據(jù)庫(kù)的連接。也可以動(dòng)態(tài)創(chuàng)建但是復(fù)用已有的連接。這些連接被存儲(chǔ)到一個(gè)共享的資源數(shù)據(jù)結(jié)構(gòu)，稱為連接池。這是典型的生產(chǎn)者-消費(fèi)者并發(fā)模型。每個(gè)線程在需要訪問(wèn)數(shù)據(jù)庫(kù)時(shí)借用（borrow）一個(gè)連接，使用完成則釋放（release）連接回到連接池供其他線程使用。比較好的線程池構(gòu)件會(huì)有二個(gè)參數(shù)動(dòng)態(tài)控制線程池的大小：最小數(shù)量和最大數(shù)量。最小數(shù)量指即使負(fù)載很輕，也保持一個(gè)最小數(shù)目的數(shù)據(jù)庫(kù)連接以備不時(shí)之需。當(dāng)同時(shí)訪問(wèn)數(shù)據(jù)庫(kù)的線程數(shù)超過(guò)最小數(shù)量時(shí)，則動(dòng)態(tài)創(chuàng)建更多連接。最大數(shù)量則是允許的最大數(shù)據(jù)庫(kù)連接數(shù)量，當(dāng)最大數(shù)目的連接都在使用而有新的線程需要訪問(wèn)數(shù)據(jù)庫(kù)時(shí)，則新的線程會(huì)被阻塞直到有連接被釋放回連接池。當(dāng)負(fù)載變低，池里的連接數(shù)目超過(guò)最小數(shù)目而只有低于或等于最小數(shù)目的連接被使用時(shí)，超過(guò)最小數(shù)目的連接會(huì)被關(guān)閉和刪除以便節(jié)省系統(tǒng)資源。

連接池的實(shí)際應(yīng)用中，最擔(dān)心的問(wèn)題就是借了不還的這種讓其他人無(wú)資源可用的人品問(wèn)題。編碼邏輯錯(cuò)誤或者釋放連接放代碼沒(méi)有放到 finally 部分都會(huì)導(dǎo)致連接池資源枯竭從而造成系統(tǒng)變慢甚至完全阻塞的情況。這種情況類似于內(nèi)存泄露，因而也叫連接泄露，是常常發(fā)生而且難以發(fā)現(xiàn)的問(wèn)題。因此檢測(cè)連接泄露并報(bào)警是線程池實(shí)現(xiàn)的基本需要。

連接在被使用時(shí)運(yùn)行在借用它的線程里面，并不是運(yùn)行在新的線程里面。但是因?yàn)槊總€(gè)連接在使用中要實(shí)現(xiàn)超時(shí) timeout 機(jī)制，官方的 Java.sql.Connection.setNetworkTimeout API的接口定義是 setNetworkTimeoutExecutor executor, int milliseconds)。此處需要指定一個(gè)線程池來(lái)處理超時(shí)的錯(cuò)誤報(bào)告。也就是每一個(gè)連接運(yùn)行數(shù)據(jù)庫(kù)訪問(wèn)時(shí)，都會(huì)有一個(gè)后臺(tái)線程監(jiān)控響應(yīng)超時(shí)狀態(tài)。很多連接池實(shí)現(xiàn)會(huì)使用 Cached Thread Pool 或 Fixed Thread Pool。Chached Thread Pool 沒(méi)有線程數(shù)目限制，動(dòng)態(tài)創(chuàng)建和回收，適合很多動(dòng)態(tài)的短小請(qǐng)求應(yīng)用。Fixed Thread Pool 則適合比較固定的連接請(qǐng)求。

另外，網(wǎng)絡(luò)故障和具體數(shù)據(jù)庫(kù)實(shí)現(xiàn)的限制會(huì)使得連接池的連接失效。比如，MySQL 允許一個(gè)連接，無(wú)論狀態(tài)正常與否，都不能超過(guò) 8 個(gè)小時(shí)的生命。因此，雖然連接在被使用時(shí)運(yùn)行在調(diào)用的線程里面，但是連接池的管理通常需要一個(gè)或多個(gè)后臺(tái)線程來(lái)管理、維護(hù)、和檢測(cè)連接池的連接狀態(tài)，保證有指定數(shù)目的連接可用。

可以看的，雖然數(shù)據(jù)庫(kù)連接在執(zhí)行數(shù)據(jù)庫(kù)訪問(wèn)使用調(diào)用者的線程，但是連接池的實(shí)現(xiàn)通常需要二個(gè)或更多的線程池做管理和超時(shí)處理。當(dāng)然連接池的具體實(shí)現(xiàn)還要考慮很多細(xì)節(jié)，但是不直接影響應(yīng)用接口，放在文章結(jié)尾再討論。

2.2 數(shù)據(jù)庫(kù)連接池的系統(tǒng)架構(gòu)

連接池的本質(zhì)是屬于一個(gè)操作系統(tǒng)進(jìn)程（process）的計(jì)數(shù)信號(hào)量（counting Semaphore），用于控制可以并行使用數(shù)據(jù)庫(kù)連接的線程數(shù)量。在 Java SDK 有一個(gè)Semaphore Class可以用來(lái)管理各種有限數(shù)量的資源。連接池的核心管理功能是從池中分配一個(gè)數(shù)據(jù)庫(kù)連接給需要的線程，線程用完后回收連接到池中。由于連接池有限，可以并行進(jìn)行數(shù)據(jù)庫(kù)訪問(wèn)的線程數(shù)量最多是連接池的最大尺寸。如果考慮到一個(gè)應(yīng)用線程可能會(huì)用到多個(gè)數(shù)據(jù)庫(kù)連接的可能性，則可以并發(fā)訪問(wèn)數(shù)據(jù)庫(kù)的線程數(shù)目會(huì)更少。

連接池的使用者是業(yè)務(wù)應(yīng)用程序。通常有二種：一種是基于用戶/服務(wù)請(qǐng)求的 HTTP 服務(wù)線程，通常采用線程池。特點(diǎn)是線程數(shù)目動(dòng)態(tài)變化很大，數(shù)據(jù)庫(kù)的訪問(wèn)模式比較多樣，處理時(shí)間也有長(zhǎng)有短，可能有很大差別。另一種是后臺(tái)服務(wù)，其線程數(shù)目比較固定，數(shù)據(jù)庫(kù)訪問(wèn)模式和處理時(shí)間也比較穩(wěn)定。

連接池只是給業(yè)務(wù)應(yīng)用提供已建立的連接，所有的訪問(wèn)請(qǐng)求都通過(guò)連接轉(zhuǎn)發(fā)到后臺(tái)數(shù)據(jù)庫(kù)服務(wù)器。數(shù)據(jù)庫(kù)服務(wù)器通常也采用線程（PostgreSQL 每個(gè)連對(duì)應(yīng)一個(gè)進(jìn)程）池處理所有的訪問(wèn)請(qǐng)求。

具體來(lái)說(shuō)，連接池是兩個(gè)線程池的中間通道。可以看成下面的結(jié)構(gòu)：

一個(gè)或多個(gè)應(yīng)用服務(wù)進(jìn)程里面（線程池 <-> 數(shù)據(jù)庫(kù)連接池） <===============> 一個(gè)數(shù)據(jù)庫(kù)服務(wù)器線程（或進(jìn)程）池

上圖中，連接池和應(yīng)用服務(wù)線線程池在同一個(gè)進(jìn)程里面。每個(gè)訪問(wèn)數(shù)據(jù)庫(kù)的應(yīng)用服務(wù)進(jìn)程都有自己的線程池和對(duì)應(yīng)的數(shù)據(jù)庫(kù)連接池。數(shù)據(jù)庫(kù)服務(wù)器可能需要處理來(lái)自一個(gè)或多個(gè)服務(wù)器的多個(gè)應(yīng)用服務(wù)進(jìn)程內(nèi)的數(shù)據(jù)庫(kù)連接池?cái)?shù)據(jù)訪問(wèn)請(qǐng)求。

3 如何配置數(shù)據(jù)庫(kù)連接池

3.1 配置目標(biāo)

當(dāng)提到數(shù)據(jù)庫(kù)連接池的配置，一個(gè)常見也是嚴(yán)重的錯(cuò)誤是把連接池和線程池的概念混淆了。如上面系統(tǒng)架構(gòu)所示，數(shù)據(jù)庫(kù)連接池并不控制應(yīng)用端和數(shù)據(jù)庫(kù)端的線程池的大小。而且每個(gè)數(shù)據(jù)庫(kù)連接池的配置只是針對(duì)自己所在的應(yīng)用服務(wù)進(jìn)程，限制的是同一個(gè)進(jìn)程內(nèi)可以訪問(wèn)數(shù)據(jù)庫(kù)的并行線程數(shù)目。應(yīng)用服務(wù)進(jìn)程單獨(dú)管理自己的線程池，除了數(shù)據(jù)庫(kù)訪問(wèn)還有處理其他業(yè)務(wù)邏輯，并行的線程數(shù)目基本取決于服務(wù)的負(fù)載。當(dāng)應(yīng)用服務(wù)線程需要訪問(wèn)數(shù)據(jù)庫(kù)時(shí)，其并發(fā)度和阻塞數(shù)目才受到連接池尺寸的影響。

做為應(yīng)用服務(wù)和數(shù)據(jù)庫(kù)的橋梁，連接池參數(shù)配置的目標(biāo)是全局優(yōu)化。具體的優(yōu)化目的有四個(gè)：盡可能滿足應(yīng)用服務(wù)的并發(fā)數(shù)據(jù)庫(kù)訪問(wèn)，不讓數(shù)據(jù)庫(kù)服務(wù)器過(guò)載，能發(fā)現(xiàn)用了不還造成的死鎖，不浪費(fèi)系統(tǒng)資源。

盡可能滿足所有的應(yīng)用服務(wù)并發(fā)數(shù)據(jù)庫(kù)訪問(wèn)的意思很簡(jiǎn)單：所有需要訪問(wèn)數(shù)據(jù)庫(kù)的線程都可以得到需要的數(shù)據(jù)庫(kù)連接。如果一個(gè)線程用到多個(gè)連接，那么需要的連接數(shù)目也會(huì)成倍增加。這時(shí)，需要的連接池最大尺寸應(yīng)該是最大的并發(fā)數(shù)據(jù)庫(kù)訪問(wèn)線程數(shù)目乘以每個(gè)線程需要的連接數(shù)目。

不讓數(shù)據(jù)庫(kù)服務(wù)器過(guò)載是個(gè)全局的考慮。因?yàn)榭赡苡卸鄠€(gè)應(yīng)用服務(wù)器的多個(gè)連接池會(huì)同時(shí)發(fā)出請(qǐng)求。按照 PostgreSQL V11 文檔18.4.3. Resource Limits，每個(gè)連接都由一個(gè)單獨(dú)進(jìn)程來(lái)處理。每個(gè)進(jìn)程即使空閑，都會(huì)消耗不少諸如內(nèi)存，信號(hào)（semaphore), 文件/網(wǎng)絡(luò)句柄（handler），隊(duì)列等各種系統(tǒng)資源。這篇文章Number Of Database Connections 討論了 PostgreSQL V9.2 的連接數(shù)目。給出的建議公式是 ((core_count * 2) + effective_spindle_count)，也就是 CPU 核數(shù)的二倍加上硬盤軸數(shù)。MySQL 采用了不同的服務(wù)架構(gòu)，MySQL Too many connections給出的缺省連接數(shù)目為 151。這二個(gè)系統(tǒng)從具體實(shí)現(xiàn)機(jī)理、計(jì)算辦法和建議數(shù)值都有很大差別，做為應(yīng)用程序員應(yīng)該有基本的理解。

這個(gè)OLTP performance -- Concurrent Mid-tier connections視頻用一個(gè)應(yīng)用服務(wù)線程池進(jìn)行了模擬。應(yīng)用服務(wù)線程池有 9600 個(gè)不斷訪問(wèn)數(shù)據(jù)庫(kù)的線程，當(dāng)連接池尺寸為 2048 和 1024 時(shí)，數(shù)據(jù)庫(kù)處于過(guò)載狀態(tài)，有很多數(shù)據(jù)庫(kù)的的等待事件，數(shù)據(jù)庫(kù) CPU 利用率高達(dá) 95%。當(dāng)連接池減少到 96，數(shù)據(jù)庫(kù)服務(wù)器沒(méi)有等待事件，CPU 利用率 20%，數(shù)據(jù)庫(kù)訪問(wèn)請(qǐng)求等待時(shí)間從 33ms 降低到 1ms，數(shù)據(jù)庫(kù) SQL 執(zhí)行時(shí)間從 77ms 降低到 2ms。數(shù)據(jù)庫(kù)訪問(wèn)整體響應(yīng)時(shí)間從 100ms 降低到 3ms。這時(shí)一個(gè)應(yīng)用服務(wù)線程池對(duì)一個(gè)數(shù)據(jù)庫(kù)服務(wù)線程池的情況，總共 96 個(gè)連接池的數(shù)據(jù)庫(kù)處理性能遠(yuǎn)遠(yuǎn)超過(guò) 1000 個(gè)連接池的性能。數(shù)據(jù)庫(kù)服務(wù)器需要為每個(gè)連接分配資源。

能發(fā)現(xiàn)用了不還造成的阻塞也是選擇連接池實(shí)現(xiàn)的基本需求。應(yīng)用程序錯(cuò)誤會(huì)造成借了不還的情況，反復(fù)出現(xiàn)會(huì)造成連接池用完應(yīng)用長(zhǎng)期等待甚至死鎖的狀態(tài)。需要有連接借用的超時(shí)報(bào)錯(cuò)機(jī)制，而這個(gè)超時(shí)時(shí)間取決于具體應(yīng)用。

不浪費(fèi)系統(tǒng)資源是指配置過(guò)大的連接池會(huì)浪費(fèi)應(yīng)用服務(wù)器的系統(tǒng)資源，包括內(nèi)存，網(wǎng)絡(luò)端口，同步信號(hào)等。同時(shí)線程池的重啟和操作都會(huì)響應(yīng)變慢。不過(guò)應(yīng)用端連接池的開銷不是很大，資源的浪費(fèi)通常不是太大問(wèn)題。

3.2 配置方法

概念清楚，目標(biāo)明確之后，配置方法就比較容易了。連接池需要考慮二種約束：二端線程（進(jìn)程）池尺寸約束和應(yīng)用吞吐量約束。綜合考慮二種方法的結(jié)果會(huì)是比較合理的。

二端約束: 找出二端的最大值，其中小的那個(gè)值就是連接池上限。應(yīng)用服務(wù)線程池尺寸，比如 Tomcat 最大線程池尺寸缺省值為 200。如果每個(gè)線程只用一個(gè)數(shù)據(jù)庫(kù)連接，那么連接池最大數(shù)目應(yīng)該小于等于 200。如果有些請(qǐng)求用到多于一個(gè)連接，則適當(dāng)增加。如果數(shù)據(jù)庫(kù)線程（進(jìn)程）池的最大尺寸為 151, 取二個(gè)值（200， 151）中的那個(gè)小的，那么連接池最大尺寸應(yīng)該小于等于 151。如果還有其他連接池，則還要全局考慮。這個(gè)值是連接池的上線。

應(yīng)用負(fù)載約束: 考慮應(yīng)用服務(wù)的負(fù)載性質(zhì)。應(yīng)用服務(wù)可以分成二類。一類是數(shù)量變化很大的 Web 應(yīng)用服務(wù)線程池，那么連接池也可以配置成動(dòng)態(tài)的，配置相應(yīng)的最小值和最大值。另一類是像郵件服務(wù)這種固定負(fù)載的業(yè)務(wù)應(yīng)用，可以配置固定尺寸的進(jìn)程池。這二類應(yīng)用都可以按照數(shù)據(jù)庫(kù)訪問(wèn)的復(fù)雜度和響應(yīng)時(shí)間進(jìn)行估算。這里用到Little's Law：并發(fā)量 = 每秒請(qǐng)求數(shù)量 * 數(shù)據(jù)庫(kù)請(qǐng)求響應(yīng)時(shí)間。注意：這里的請(qǐng)求響應(yīng)時(shí)間包括網(wǎng)絡(luò)時(shí)間+數(shù)據(jù)庫(kù)訪問(wèn)時(shí)間。很多時(shí)候網(wǎng)絡(luò)時(shí)間大于數(shù)據(jù)庫(kù)訪問(wèn)時(shí)間。如果一個(gè)應(yīng)用線程有多個(gè)數(shù)據(jù)庫(kù)訪問(wèn)請(qǐng)求，尤其是有事物處理的時(shí)候，這個(gè)數(shù)據(jù)庫(kù)請(qǐng)求響應(yīng)時(shí)間其實(shí)是持有連接的時(shí)間，公式變?yōu)?#xff1a;并發(fā)量（連接數(shù)）： 每秒請(qǐng)求數(shù) （QPS）* 數(shù)據(jù)庫(kù)連接持有時(shí)間。

如果每秒有 100 個(gè)數(shù)據(jù)庫(kù)訪問(wèn)請(qǐng)求，每個(gè)數(shù)據(jù)庫(kù)訪問(wèn)請(qǐng)求需要 20ms，那么并行量是 100 * 0.02 = 2,2 個(gè)并發(fā)數(shù)據(jù)庫(kù)連接就可以了。同理，如果每個(gè)請(qǐng)求需要 100ms，那么就需要 10 個(gè)并發(fā)連接。

僅僅考慮二端線程（進(jìn)程）池的尺寸會(huì)配置過(guò)大的連接池，因?yàn)檫@是系統(tǒng)的上限。由于數(shù)據(jù)庫(kù)訪問(wèn)僅僅是應(yīng)用線程的一部分工作。 原因是在線程數(shù)目計(jì)算公式里：線程數(shù)目 = CPU核數(shù) * CPU 利用率 * (1 + 等待時(shí)間 / CPU計(jì)算時(shí)間)， 數(shù)據(jù)庫(kù)的等待時(shí)間只是線程所有操作的等待時(shí)間的一部分。

僅僅配置最小和最大連接數(shù)目?jī)H僅是開始，根據(jù)具體實(shí)現(xiàn)不同，還需要配置連接生命周期，連接超時(shí)，未釋放連接以及健康監(jiān)控等其他參數(shù)。具體需要參考連接池的使用文檔。

3.3 一個(gè)表面相關(guān)，其實(shí)無(wú)關(guān)的計(jì)算公式

因?yàn)檫B接池和線程池經(jīng)常被混淆，這里有必要介紹另外一個(gè)經(jīng)常提到但是無(wú)關(guān)的線程數(shù)目計(jì)算公式。這個(gè)公式來(lái)自每個(gè) Java 程序員都應(yīng)該閱讀的Java Concurrency in Practice。在原著 8.2 節(jié), 第 171 頁(yè)作者給出了著名的線程數(shù)目計(jì)算公式：線程數(shù)目 = CPU核數(shù) * CPU 利用率 * (1 + 等待時(shí)間 / CPU計(jì)算時(shí)間)。這個(gè)公式考慮了計(jì)算密集（計(jì)算時(shí)間）和 I/O 密集（等待時(shí)間）的不同處理模式。計(jì)算進(jìn)程的 CPU 使用率給出了具體的技術(shù)方式和 Script。可是這個(gè)公式可以用于應(yīng)用服務(wù)線程池或任何線程池的尺寸估算，但是與數(shù)據(jù)庫(kù)連接池的大小估算無(wú)關(guān)。因?yàn)檫M(jìn)程池并不能控制應(yīng)用服務(wù)的線程數(shù)目，它控制的是可并發(fā)的數(shù)據(jù)庫(kù)訪問(wèn)線程數(shù)目。這些線程使用數(shù)據(jù)庫(kù)連接完成網(wǎng)絡(luò)服務(wù)和遠(yuǎn)程數(shù)據(jù)庫(kù)的異步操作，此時(shí)基本沒(méi)有使用本機(jī)的 CPU 計(jì)算時(shí)間。套用公式會(huì)得出非常大的數(shù)字，沒(méi)有實(shí)際意義。

4 Spring + MySQL 的應(yīng)用的連接池配置

如上所述，配置 Spring 連接池首先要考慮到其使用的 HTTP 服務(wù)的線程池配置和后端數(shù)據(jù)庫(kù)服務(wù)器的連接數(shù)配置。其次是應(yīng)用的特點(diǎn)。

4.1 應(yīng)用服務(wù)的線程數(shù)

Spring 的 server.tomcat.max-threads 參數(shù)給出了最大的并行線程數(shù)目，缺省值是 200. 由于才有特殊處理，這些線程可以處理的更大的 HTTP 連接數(shù)目 server.tomcat.max-connections，缺省值是 10000. spring.task.execution.pool.max-threads則控制使用@Async的最大線程數(shù)目, 缺省值沒(méi)有限制。最好按應(yīng)用特點(diǎn)配置一個(gè)范圍。

4.2 數(shù)據(jù)庫(kù)方面的連接數(shù)

MySQL 數(shù)據(jù)庫(kù)用max_connections環(huán)境變量設(shè)置最大連接數(shù)，缺省值是 151. 多數(shù)建議都是根據(jù)內(nèi)存大小或應(yīng)用負(fù)載來(lái)設(shè)置這個(gè)值。

4.3 基本參數(shù)設(shè)置

Spring 缺省使用HikariCP。

需要配置的基本參數(shù)如下。

• maximumPoolSize： 最大的連接數(shù)目。超過(guò)這個(gè)數(shù)目，新的數(shù)據(jù)庫(kù)訪問(wèn)線程會(huì)被阻塞。缺省值是 10。
• minimumIdle： 最小的連接數(shù)目。缺省值是最大連接數(shù)目。
• leakDetectionThreshold： 未返回連接報(bào)警時(shí)間。缺省值是 0，不啟用。這個(gè)值如果大于 0，如果一個(gè)連接被使用的時(shí)間超過(guò)這個(gè)值則會(huì)日志報(bào)警（warn 級(jí)別的 log 信息）。考慮到網(wǎng)絡(luò)負(fù)載情況，可以設(shè)置為最大數(shù)據(jù)庫(kù)請(qǐng)求時(shí)長(zhǎng)的 3 倍或 5 倍。如果沒(méi)有這個(gè)報(bào)警，程序的正確性很難保證。
• maxLifetime：最大的連接生命時(shí)間。缺省值是 30 分鐘。官方文檔建議設(shè)置這個(gè)值為稍小于數(shù)據(jù)庫(kù)的最大連接生命時(shí)間。MySQL 的缺省值為 8 小時(shí)。可以設(shè)置為 7 小時(shí) 59 分鐘以避免每半個(gè)小時(shí)重建一次連接。

4.4 針對(duì)數(shù)據(jù)庫(kù)的優(yōu)化設(shè)置

HikariCP 建議的 MySQL 配置參數(shù)和建議值如下，這些配置有助于提高數(shù)據(jù)庫(kù)訪問(wèn)的性能.這些參數(shù)的缺省值在MySQL JDBC 文檔

• prepStmtCacheSize： 250-500. Default: 25.
• prepStmtCacheSqlLimit： 2048. Default: 256.
• cachePrepStmts： true. Default: false.
• useServerPrepStmts： true. Default: false.

4.5 針對(duì)業(yè)務(wù)未來(lái)發(fā)展預(yù)測(cè)的調(diào)整

目前為止，我們的所有計(jì)算、配置都是根據(jù)現(xiàn)有軟硬件配置、業(yè)務(wù)規(guī)模來(lái)進(jìn)行計(jì)算的，然后業(yè)務(wù)是不斷發(fā)展的，所以，對(duì)于業(yè)務(wù)的未來(lái)發(fā)展，我們也應(yīng)該有個(gè)相應(yīng)的考慮。如，假設(shè)一年之后，我們的業(yè)務(wù)量增長(zhǎng)了一倍，那么我們相應(yīng)的，可以將我們的固定計(jì)算擴(kuò)大一倍（前提是未到機(jī)器上限）。這部分與業(yè)務(wù)預(yù)估息息相關(guān)，最好的建議是一開始就按照機(jī)器的上限來(lái)進(jìn)行配置，并實(shí)時(shí)監(jiān)控各方面的業(yè)務(wù)性能，待現(xiàn)有機(jī)器支撐不住時(shí)，可及時(shí)水平擴(kuò)展。（這里如果使用了動(dòng)態(tài)伸縮方面技術(shù)的話，便大可放心，不用手動(dòng)調(diào)整了）。

5 其他

5.1 連接池其他實(shí)現(xiàn)細(xì)節(jié)

具體的連接池實(shí)現(xiàn)需要考慮很多應(yīng)用細(xì)節(jié)。

• 數(shù)據(jù)庫(kù)連接的使用還牽涉到事物處理，Spring 的同步數(shù)據(jù)庫(kù)訪問(wèn)采用 ThreadLocal 保存事物處理相關(guān)狀態(tài)。所以連接池執(zhí)行數(shù)據(jù)庫(kù)訪問(wèn)時(shí)必須在調(diào)用者的線程，不能運(yùn)行在新的線程。Spring 異步數(shù)據(jù)庫(kù)訪問(wèn)則可以跨線程。
• 多余的連接不會(huì)立即關(guān)閉，而是會(huì)等待一段空閑時(shí)間（idle time）再關(guān)閉。
• 連接有最長(zhǎng)生命時(shí)間限制，即使連接池不管，數(shù)據(jù)庫(kù)也會(huì)自動(dòng)關(guān)閉超過(guò)生命時(shí)間的連接。在 MySql 里面，連接最長(zhǎng)生命時(shí)間是 8 個(gè)小時(shí)。連接池需要定期監(jiān)控清理無(wú)效的連接。
• 連接池需要定期檢查數(shù)據(jù)庫(kù)的可用狀態(tài)甚至響應(yīng)時(shí)間，及時(shí)報(bào)告健康狀態(tài)。HikariCP Dropwizard HealthChecks是一個(gè)例子。
• 當(dāng)需要為新線程訪問(wèn)創(chuàng)建連接時(shí)，新線程應(yīng)該等待池里第一個(gè)可用的連接而不必等待因它而創(chuàng)建的線程。HikariCP 的文檔Welcome to the Jungle 描述了這種實(shí)現(xiàn)的優(yōu)點(diǎn)：可以避免創(chuàng)建很多不必要的連接并且有更好的性能。Hikari 用 5 個(gè)連接處理了 50 個(gè)突發(fā)的數(shù)據(jù)庫(kù)短時(shí)訪問(wèn)請(qǐng)求，即提高了響應(yīng)速度，也避免了創(chuàng)建額外的連接。
• 數(shù)據(jù)庫(kù)各種異常的處理。Bad Behavior: Handling Database Down 給出里不同連接池構(gòu)件實(shí)現(xiàn)對(duì)于線程阻塞 timeout 的不同處理方式。很多連接池構(gòu)件不能正確處理。
• 線程池的性能監(jiān)視。HikariCP Dropwizard Metrics 給出了監(jiān)視的性能指標(biāo)。
• 線程阻塞的機(jī)制以及相關(guān)數(shù)據(jù)結(jié)構(gòu)對(duì)連接池的性能有很大影響。Down the Rabbit Hole給出了 Java 里的優(yōu)化方法。壞處是里面有些優(yōu)化過(guò)于瑣碎，使得代碼晦澀難懂而且需要額外維護(hù)工作。

5.2 一些參考缺省配置

HikariCP: DEFAULT_POOL_SIZE = 10

DBCP: Max pool size : 8

c3p0: MIN_POOL_SIZE = 3, MAX_POOL_SIZE = 15

JIRA Tuning database connections：pool-max-size = 20. 和前三個(gè)不同，這是一個(gè)數(shù)據(jù)庫(kù)應(yīng)用程序。里面討論了數(shù)據(jù)庫(kù)的連接數(shù)目，提到一方面數(shù)據(jù)庫(kù)可以支持?jǐn)?shù)百并行連接，另一方面應(yīng)用服務(wù)端的連接還是比較耗費(fèi)資源，建議在允許的情況下盡可能設(shè)成小的數(shù)字。

5.3 題外話

網(wǎng)上搜了很多，沒(méi)有想到這么簡(jiǎn)單的一個(gè)數(shù)據(jù)庫(kù)連接池配置問(wèn)題竟然沒(méi)有比較全面、明確的文檔。把連接池和線程池搞混的的人很多。甚至實(shí)施 HikariCP 的程序員在初始化連接池的時(shí)候使用了錯(cuò)誤的線程池?cái)?shù)目。創(chuàng)建線程池的開銷主要是網(wǎng)絡(luò)和遠(yuǎn)程數(shù)據(jù)庫(kù)服務(wù)請(qǐng)求的延遲，幾乎不耗費(fèi) CPU 資源。按照線程計(jì)算公式，此時(shí)線程池可以很大。可是 HikariCP 的程序員還是僅僅用了Runtime.getRuntime().availableProcessors()數(shù)目的線程用于創(chuàng)建連接池。正確的數(shù)目應(yīng)該是配置的最小連接池?cái)?shù)目，這樣既不浪費(fèi)（在連接數(shù)小于 CPU 核數(shù)時(shí)），也有最好的性能（在連接數(shù)超過(guò) CPU 核數(shù)時(shí)）。參考這個(gè) Issue：Change the thread pool size to minimumIdle on blocked initialization。 這種錯(cuò)誤并不奇怪，因?yàn)?HikariCP 的代碼風(fēng)格比較糟糕。很多廣泛使用的開源軟件其實(shí)代碼質(zhì)量并不高，每個(gè)人都應(yīng)該搞清楚概念和問(wèn)題的本質(zhì)，多理解其他人的想法，但是保持懷疑態(tài)度和獨(dú)立思考能力。

轉(zhuǎn)載于:https://juejin.im/post/5ce897386fb9a07ef819d7eb

總結(jié)

以上是生活随笔為你收集整理的数据库连接池设置的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。