解讀dbcp自動重連那些事

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.