為什么80%的碼農(nóng)都做不了架構(gòu)師？>>> ??

最近常有數(shù)據(jù)庫和網(wǎng)絡(luò)設(shè)備升級(jí)和搬遷等事情，而各個(gè)應(yīng)用都是基于數(shù)據(jù)庫連接池做的，大部分都是基于C3P0，數(shù)據(jù)庫或網(wǎng)絡(luò)狀況的變動(dòng)都會(huì)導(dǎo)致客戶端連接池中的connection失效，如何剔除這些blocked connection就和C3P0的各個(gè)配置息息相關(guān)。這兩天，搭了個(gè)實(shí)驗(yàn)環(huán)境，根據(jù)C3P0的配置說明?和實(shí)驗(yàn)結(jié)果，把C3P0關(guān)于這塊的機(jī)制解析了一番。先看看我的結(jié)論：

1）C3P0容錯(cuò)和自動(dòng)重連與以下配置參數(shù)有關(guān)：

• breakAfterAcquireFailure?：true表示pool向數(shù)據(jù)庫請(qǐng)求連接失敗后標(biāo)記整個(gè)pool為block并close，就算后端數(shù)據(jù)庫恢復(fù)正常也不進(jìn)行重連，客戶端對(duì)pool的請(qǐng)求都拒絕掉。false表示不會(huì)標(biāo)記?pool為block，新的請(qǐng)求都會(huì)嘗試去數(shù)據(jù)庫請(qǐng)求connection。默認(rèn)為false。因此，如果想讓數(shù)據(jù)庫和網(wǎng)絡(luò)故障恢復(fù)之后，pool能繼續(xù)請(qǐng)求正常資源必須把此項(xiàng)配置設(shè)為false
• idleConnectionTestPeriod?：C3P0會(huì)有一個(gè)Task檢測(cè)pool內(nèi)的連接是否正常，此參數(shù)就是Task運(yùn)行的頻率。默認(rèn)值為0，表示不進(jìn)行檢測(cè)。
• testConnectionOnCheckout?：true表示在每次從pool內(nèi)checkout連接的時(shí)候測(cè)試其有效性，這是個(gè)同步操作，因此應(yīng)用端的每次數(shù)據(jù)庫調(diào)用，都會(huì)先通過測(cè)試sql測(cè)試其有效性，如果連接無效，會(huì)關(guān)閉此連接并剔除出pool，并嘗試從pool內(nèi)取其他連接，默認(rèn)為false，此特性要慎用，會(huì)造成至少多一倍的數(shù)據(jù)庫調(diào)用。
• testConnectionOnCheckin?：true表示每次把連接checkin到pool里的時(shí)候測(cè)試其有效性，因?yàn)槭莻€(gè)事后操作，所以是異步的，應(yīng)用端不需要等待測(cè)試結(jié)果，但同樣會(huì)造成至少多一倍的數(shù)據(jù)庫調(diào)用。
• acquireRetryAttempts?和acquireRetryDelay?：pool請(qǐng)求取連接失敗后重試的次數(shù)和重試的頻率。請(qǐng)求連接會(huì)發(fā)生在pool內(nèi)連接少于min值或則等待請(qǐng)求數(shù)>池內(nèi)能提供的連接數(shù)

• automaticTestTable?、connectionTesterClassName?、preferredTestQuery?：表示測(cè)試方式，默認(rèn)是采用DatabaseMetaData.getTables()來測(cè)試connection的有效性，但可以通過以上配置來定制化測(cè)試語句，通過其名字就很好理解其含義，無需過多解釋

• maxIdleTime?和?maxConnectionAge?：表示connection的時(shí)效性，maxIdleTime和maxConnectionAge不同之處在于，?maxIdleTime表示idle狀態(tài)的connection能存活的最大時(shí)間，而?maxConnectionAge表示connection能存活的絕對(duì)時(shí)間

2）應(yīng)用端getConnection拋出exception時(shí)，?C3P0會(huì)測(cè)試其connection的有效性，并根據(jù)狀態(tài)處理此connection，但應(yīng)用端不會(huì)重調(diào)。

3）無論是網(wǎng)絡(luò)問題還是遠(yuǎn)端數(shù)據(jù)庫服務(wù)器，就算恢復(fù)正常后，客戶端pool內(nèi)其已存在的connection都會(huì)失效，要保證應(yīng)用端調(diào)用無誤，必須在checkout到應(yīng)用端之前刷新這些無效connection

4）breakAfterAcquireFailure=false是關(guān)鍵。如果?breakAfterAcquireFailure=true?，一旦pool向數(shù)據(jù)庫請(qǐng)求連接失敗，就會(huì)標(biāo)記pool block并關(guān)閉pool，這樣無論數(shù)據(jù)庫是否恢復(fù)正常，應(yīng)用端都無法從pool拿到連接

5）要想保證網(wǎng)絡(luò)和數(shù)據(jù)庫瞬間的失效100%不會(huì)造成應(yīng)用端getConnection失敗必須開啟testConnectionOnCheckout。但此特性的代價(jià)巨大，建議在應(yīng)用端做容錯(cuò)。

6）推薦使用?idleConnectionTestPeriod。可以根據(jù)應(yīng)用調(diào)用頻率權(quán)衡一個(gè)檢查pool的頻率，這樣可以在保證性能損耗不大情況下，盡可能的保證pool內(nèi)connection的有效性

7）若嫌DatabaseMetaData.getTables()性能不好，可以嘗試通過配置automaticTestTable、connectionTesterClassName、preferredTestQuery來找到一個(gè)性能最好的測(cè)試語句，只要能驗(yàn)證connection有效就行

綜上所述，要想保證性能的前提下，本人推薦的配置組合如下：

breakAfterAcquireFailure: false
testConnectionOnCheckout: false
testConnectionOnCheckin: false
idleConnectionTestPeriod: 60
acquireRetryAttempts: 10
acquireRetryDelay: 1000

但需要注意的是以上的配置不能保證100%應(yīng)用端getConnection無誤，如果應(yīng)用端不能發(fā)生getConnection錯(cuò)誤，需要自行考慮容錯(cuò)和重試機(jī)制。

在以上配置下，當(dāng)網(wǎng)絡(luò)或數(shù)據(jù)庫發(fā)生瞬間變動(dòng)的情況下，會(huì)有如下事情發(fā)生：

1）自動(dòng)測(cè)試idleConnection的?task輪訓(xùn)檢測(cè)pool，對(duì)每個(gè)connction通過DatabaseMetaData.getTables()來測(cè)試有效性，并剔除無效連接。

2）根據(jù)請(qǐng)求情況和配置，pool向數(shù)據(jù)庫請(qǐng)求新連接并加入池內(nèi)

3）應(yīng)用端getConnection->是否發(fā)生異常->如果發(fā)生異常，檢驗(yàn)其有效性，并剔除出pool->如果沒有發(fā)生異常（自動(dòng)檢查task之前已檢測(cè)），調(diào)用成功

轉(zhuǎn)載于:https://my.oschina.net/jsan/blog/34968

總結(jié)

以上是生活随笔為你收集整理的关于C3P0容错和自动重连特性的研究的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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