數據庫鏈接 常見的問題:
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是否已經是壞了的,如果壞了就直接丟了,就直接給丟棄了。
代碼層面:
1. 在dbcp中PoolingDataSource(實現DataSource接口)調用 PoolableConnection(dbcp connnection 相關的pool delegate操作)進行相應關閉時,會檢查 _conn.isClosed() ,針對DataSource如果isClosed返回爲 true的則不調用returnObject,直接丟棄了鏈接。
2. _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所謂的自動重連的3個參數,
<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.
dbcp的基本配置
相關配置說明:
initialSize :連接池啓動時創建的初始化連接數量(默認值爲0)
maxActive :連接池中可同時連接的最大的連接數(默認值爲8,調整爲20,高峯單機器在20併發左右,自己根據應用場景定)
maxIdle:連接池中最大的空閒的連接數,超過的空閒連接將被釋放,如果設置爲負數表示不限制(默認爲8個,maxIdle不能設置太小,因爲假如在高負載的情況下,連接的打開時間比關閉的時間快,會引起連接池中idle的個數 上升超過maxIdle,而造成頻繁的連接銷燬和創建,類似於jvm參數中的Xmx設置)
minIdle:連接池中最小的空閒的連接數,低於這個數量會被創建新的連接(默認爲0,調整爲5,該參數越接近maxIdle,性能越好,因爲連接的創建和銷燬,都是需要消耗資源的;但是不能太大,因爲在機器很空閒的時候,也會創建低於minidle個數的連接,類似於jvm參數中的Xmn設置)
maxWait :最大等待時間,當沒有可用連接時,連接池等待連接釋放的最大時間,超過該時間限制會拋出異常,如果設置-1表示無限等待(默認爲無限,調整爲60000ms,避免因線程池不夠用,而導致請求被無限制掛起)
poolPreparedStatements:開啓池的prepared(默認是false,未調整,經過測試,開啓後的性能沒有關閉的好。)
maxOpenPreparedStatements:開啓池的prepared 後的同時最大連接數(默認無限制,同上,未配置)
minEvictableIdleTimeMillis :連接池中連接,在時間段內一直空閒, 被逐出連接池的時間
(默認爲30分鐘,可以適當做調整,需要和後端服務端的策略配置相關)
removeAbandonedTimeout :超過時間限制,回收沒有用(廢棄)的連接(默認爲 300秒,調整爲180)
removeAbandoned :超過removeAbandonedTimeout時間後,是否進 行沒用連接(廢棄)的回收(默認爲false,調整爲true)
removeAbandoned參數解釋:
如果開啓了removeAbandoned,當getNumIdle() < 2) and (getNumActive() > getMaxActive() - 3)時被觸發.
舉例當maxActive=20, 活動連接爲18,空閒連接爲1時可以觸發"removeAbandoned".但是活動連接只有在沒有被使用的時間超 過"removeAbandonedTimeout"時才被回收
logAbandoned: 標記當連接被回收時是否打印程序的stack traces日誌(默認爲false,未調整)
一般會是幾種情況出現需要removeAbandoned:
代碼未在finally釋放connection , 不過我們都用sqlmapClientTemplate,底層都有鏈接釋放的過程
遇到數據庫死鎖。以前遇到過後端存儲過程做了鎖表操作,導致前臺集羣中連接池全都被block住,後續的業務處理因爲拿不到鏈接所有都處理失敗了。
一份優化過的配置:
[html] view plaincopy
<property name="maxActive"><value>20</value></property>
<property name="initialSize"><value>1</value></property>
<property name="maxWait"><value>60000</value></property>
<property name="maxIdle"><value>20</value></property>
<property name="minIdle"><value>3</value></property>
<property name="removeAbandoned"><value>true</value></property>
<property name="removeAbandonedTimeout"><value>180</value></property>
<property name="connectionProperties"><value>clientEncoding=GBK</value></property>
2. dbcp的鏈接validate配置
dbcp是採用了commons-pool做爲其連接池管理,testOnBorrow,testOnReturn, testWhileIdle是pool是提供的幾種校驗機制,通過外部鉤子的方式回調dbcp的相關數據庫鏈接(validationQuery)校驗
dbcp相關外部鉤子類:PoolableConnectionFactory,繼承於common-pool PoolableObjectFactory
dbcp通過GenericObjectPool這一入口,進行連接池的borrow,return處理
testOnBorrow : 顧明思義,就是在進行borrowObject進行處理時,對拿到的connection進行validateObject校驗
testOnReturn : 顧明思義,就是在進行returnObject對返回的connection進行validateObject校驗,個人覺得對數據庫連接池的管理意義不大
testWhileIdle : 關注的重點,GenericObjectPool中針對pool管理,起了一個Evict的TimerTask定時線程進行控制(可通過設置參數timeBetweenEvictionRunsMillis>0),定時對線程池中的鏈接進行validateObject校驗,對無效的鏈接進行關閉後,會調用ensureMinIdle,適當建立鏈接保證最小的minIdle連接數。
timeBetweenEvictionRunsMillis,設置的Evict線程的時間,單位ms,大於0纔會開啓evict檢查線程
validateQuery, 代表檢查的sql
validateQueryTimeout, 代表在執行檢查時,通過statement設置,statement.setQueryTimeout(validationQueryTimeout)
numTestsPerEvictionRun,代表每次檢查鏈接的數量,建議設置和maxActive一樣大,這樣每次可以有效檢查所有的鏈接.
[html] view plaincopy
<property name="testWhileIdle"><value>true</value></property> <!-- 打開檢查,用異步線程evict進行檢查 -->
<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>20</value></property>
相關配置需求:
目前網站的應用大部分的瓶頸還是在I/O這一塊,大部分的I/O還是在數據庫的這一層面上,每一個請求可能會調用10來次SQL查詢,如果不走事務,一個請求會重複獲取鏈接,如果每次獲取鏈接都進行validateObject,性能開銷不是很能接受,可以假定一次SQL操作消毫0.5~1ms(一般走了網絡請求基本就這數)
網站異常數據庫重啓,網絡異常斷開的頻率是非常低的,一般也就在數據庫升級,演習維護時纔會進行,而且一般也是選在晚上,訪問量相對比較低的請求,而且一般會有人員值班關注,所以異步的validateObject是可以接受,但一個前提需要確保能保證在一個合理的時間段內,數據庫能完成自動重聯。