解讀dbcp自動重連那些事

能夠後另外一篇作對比：http://agapple.iteye.com/blog/772507

一樣的內容，不一樣的描述方式，不同的效果.

 

Hi all :

最近在作 offerdetail 優化時，替換了數據庫驅動，從 c3p0 0.9.1 -> dbcp 1.4 ， 順便研究了下 dbcp 的自動重連的一套機制，也作一下分享，你們周知一下。

 

數據庫連接　常見的問題：

1. 數據庫意外重啓後，原先的數據庫鏈接池能自動廢棄老的無用的連接，創建新的數據庫連接

2. 網絡異常中斷後，原先的創建的 tcp 連接，應該能進行自動切換。好比網站演習中的交換機重啓會致使網絡瞬斷

3. 分佈式數據庫中間件，好比 cobar 會定時的將空閒連接異常關閉，客戶端會出現半開的空閒連接。

 

大體思考解決思路：

1.      sql 心跳檢查 ( 主動式 )

2.      拿連接嘗試一下，發現處理失敗丟棄連接，探雷的請求會失敗幾個　 ( 犧牲小我，完成大個人精神 )

3.      設置合理的空閒連接的超時時間，避免半開連接 ( 懶模式，解決半開連接 )

 

 

下面咱們來看看，在 dbcp 中是如何實現。

sql 心跳檢查

sql validate 配置

<property name= "testWhileIdle" ><value> true </value></property>

<property name= "testOnBorrow" ><value> false </value></property>

<property name= "testOnReturn" ><value> false </value></property>

<property name= "validationQuery" ><value>select sysdate from dual</value></property>

<property name= "validationQueryTimeout" ><value>1</value></property>

<property name= "timeBetweenEvictionRunsMillis" ><value>30000</value></property>

<property name= "numTestsPerEvictionRun" ><value>16</value></property>

參數說明

  

   dbcp 是採用了 commons-pool 作爲其鏈接池管理， testOnBorrow,testOnReturn, testWhileIdle 是 pool 是提供的幾種校驗機制，經過外部鉤子的方式回調 dbcp 的相關數據庫連接 (validationQuery) 校驗 , dbcp 相關外部鉤子類： PoolableConnectionFactory, 繼承於 common-pool PoolableObjectFactory , dbcp 經過 GenericObjectPool 這一入口，進行鏈接池的 borrow,return 處理。

具體參數描述：

   1. testOnBorrow : 顧明思義，就是在進行borrowObject進行處理時，對拿到的connection進行validateObject校驗

   2. testOnReturn : 顧明思義，就是在進行returnObject對返回的connection進行validateObject校驗，我的以爲對數據庫鏈接池的管理意義不大

   3. testWhileIdle : 關注的重點，GenericObjectPool中針對pool管理，起了一個 異步Evict的TimerTask定時線程進行控制 ( 可經過設置參數 timeBetweenEvictionRunsMillis>0), 定時對線程池中的連接進行validateObject校驗，對無效的連接進行關閉後，會調用ensureMinIdle，適當創建連接保證最小的minIdle鏈接數。

   4. timeBetweenEvictionRunsMillis, 設置的Evict線程的時間，單位ms，大於0纔會開啓evict檢查線程

   5. validateQuery ， 表明檢查的sql

   6. validateQueryTimeout ， 表明在執行檢查時，經過statement設置，statement.setQueryTimeout(validationQueryTimeout)

   7. numTestsPerEvictionRun ，表明每次檢查連接的數量，建議設置和maxActive同樣大，這樣每次能夠有效檢查全部的連接.

Sql 心跳檢查幾點思考：

1. 性能問題。

目前網站的應用大部分的瓶頸仍是在I/O這一塊，大部分的I/O仍是在數據庫的這一層面上，每個請求可能會調用10來次SQL查詢，若是不走事務，一個請求會重複獲取連接，若是每次獲取連接,好比在testOnBorrow都進行validateObject，性能開銷不是很能接受，能夠假定一次SQL操做消毫0.5~1ms(通常走了網絡請求基本就這數)

2 ．成本和收益

網站異常數據庫重啓，網絡異常斷開的頻率是很是低的，通常也就在數據庫升級，演習維護時纔會進行，並且通常也是選在晚上，訪問量相對比較低的請求，並且通常會有人員值班關注，因此異步的validateObject是能夠接受，但一個前提須要確保能保證在一個合理的時間段內，數據庫能完成自動重聯。

 

請求探雷

相關配置

dbcp 自身默認支持，不須要配置

原理描述

common-pools 經過borrowObject , returnObject完成鏈接的獲取和釋放，正常的狀況是一次請求中borrow和return是一對的，有借就有還。

但在準備returnObject時，dbcp會作一件事，就是看看這個object是否已是壞了的，若是壞了就直接丟了，就直接給丟棄了。

 

代碼層面：

１.　在dbcp中PoolingDataSource(實現DataSource接口)調用 PoolableConnection(dbcp connnection 相關的pool delegate操做)進行相應關閉時，會檢查 _conn.isClosed() ，針對DataSource若是isClosed返回爲 true的則不調用returnObject，直接丟棄了連接。

２.　_conn.isClosed()是否保險，從jdk的api描述中： A connection is closed if the method close has been called on it or if certain fatal errors have occurred. 裏面提供兩種狀況，一種就是被調用了closed方法，另外一種就是出現一些異常，說的比較含糊。

 

空閒連接檢查

相關配置

<property name="minEvictableIdleTimeMillis "><value>18000000</value></property>

<property name="removeAbandoned" ><value>true</value></property> 

<property name="removeAbandonedTimeout "><value>180</value></property>

參數說明

1. minEvictableIdleTimeMillis 　dbcp默認是30分，須要開啓異步線程Evict，不然不生效。原理很簡單，就是經過一個異步線程，每次檢查connnection上一次使用的時間戳，看看是否已經超過這個timeout時間設置。

2. removeAbandoned , removeAbandonedTimeout ，主要是用於在出現連接緊張時候，會掃描一些連接未超過removeAbandonedTimeout時間還未被釋放，會主動的關閉該連接。

適用狀況

1. 咱們使用的cobar後端會有定時關閉空閒連接的操做，默認的空閒連接timeout時間爲1小時，和其餘oracle , mysql 各不相同，因此設置好這個空閒連接的timeout時間仍是挺重要.

 

2. 通常會是幾種狀況出現須要removeAbandoned：　

* 代碼未在finally釋放connection , 　不過咱們都用sqlmapClientTemplate，底層都有連接釋放的過程

* 遇到數據庫死鎖 。之前遇到事後端存儲過程作了鎖表操做，致使前臺集羣中鏈接池全都被block住，後續的業務處理由於拿不到連接全部都處理失敗了。

 

 

聊聊 c3p0 配置

還有咱們配置的c3p0所謂的自動重連的３個參數，

<prop key="acquireRetryAttempts">30</prop>

    <prop key="acquireRetryDelay">1000</prop>

    <prop key="breakAfterAcquireFailure">false</prop>

 

我的以爲就是一個誤導 ，這幾個配置只是在從鏈接池獲取連接時，獲取失敗多嘗試幾回，由於咱們從pool從獲取連接最多隻會等待固定timeout時間。

若是要達到自動重連的效果，必需要c3p0支持請求探雷或者是sql心跳檢查功能，能自動的剔除無效的連接。　

可見c3p0官方文檔描述：http://www.mchange.com/projects/c3p0/index.html#configuring_recovery

 

最後：

Dbcp 將是咱們之後數據庫驅動選擇的趨勢，最後咱們如何選擇如何自動重連，這個也得根據咱們的應用場景而定。好比只讀的web系統，後臺業務系統，任務系統可能處理方式就不一樣。

只讀Web系統：可採起請求探雷的策略，也就失敗鏈接池個數的請求，失敗了頁面刷新一次就好。

後臺業務系統：通常業務都涉及數據庫的寫操做，不少數據不可重入，一次處理失敗後就只能靠手工干預處理。這時候得考慮是否須要使用sql心跳檢查，好比testOnBorrow或者testWhileIdle.