druid 數據庫鏈接池

轉自：http://blog.csdn.net/jiangguilong2000/article/details/68483886

根據綜合性能，可靠性，穩定性，擴展性，易用性等因素替換成最優的數據庫鏈接池。

Druid:druid-1.0.29

數據庫  MySQL.5.6.17

替換目標:替換掉C3P0,用druid來替換

替換緣由:

 

一、性能方面 hikariCP>druid>tomcat-jdbc>dbcp>c3p0 。hikariCP的高性能得益於最大限度的避免鎖競爭。

二、druid功能最爲全面，sql攔截等功能，統計數據較爲全面，具備良好的擴展性。

三、綜合性能，擴展性等方面，可考慮使用druid或者hikariCP鏈接池，比較方便對jdbc接口進行監控跟蹤等。

四、可開啓prepareStatement緩存，對性能會有大概20%的提高。

 

• psCache是connection私有的，因此不存在線程競爭的問題，開啓pscache不會存在競爭的性能損耗。
• psCache的key爲prepare執行的sql和catalog等，value對應的爲prepareStatement對象。開啓緩存主要是減小了解析sql的開銷。

 

五、3p0歷史悠久，代碼及其複雜，不利於維護。而且存在deadlock的潛在風險。

六、Druid能夠打印SQL，慢查詢方面的日誌

Druid 參數

 

配置參數	缺省值	遊戲服設置的值	參數說明
initialSize	0	4	初始化鏈接數量
minIdle	0	4	最小空閒鏈接數
maxActive	8	8	最大併發鏈接數
maxWait	-1L	60000	獲取鏈接時最大等待時間，單位毫秒。配置了maxWait以後， 缺省啓用公平鎖，併發效率會有所降低， 若是須要能夠經過配置useUnfairLock屬性爲true使用非公平鎖。
timeBetweenEvictionRunsMillis	60000	60000	配置間隔多久才進行一次檢測，檢測須要關閉的空閒鏈接，單位是毫秒 Destroy線程會檢測鏈接的間隔時間
minEvictableIdleTimeMillis	1800000	1800000	配置一個鏈接在池中最小生存的時間，單位是毫秒
validationQuery	null	select 1	用來檢測鏈接是否有效的sql，要求是一個查詢語句
testOnBorrow	FALSE	FALSE	申請鏈接時執行validationQuery檢測鏈接是否有效，作了這個配置會下降性能。
testOnReturn	FALSE	FALSE	歸還鏈接時執行validationQuery檢測鏈接是否有效，作了這個配置會下降性能
testWhileIdle	TRUE	TRUE	建議配置爲true，不影響性能，而且保證安全性。 申請鏈接的時候檢測，若是 空閒時間大於 timeBetweenEvictionRunsMillis， 執行validationQuery檢測鏈接是否有效。
poolPreparedStatements	FALSE	TRUE	false 是否緩存preparedStatement，也就是PSCache。 PSCache對支持遊標的數據庫性能提高巨大，好比說oracle。 在mysql5.5如下的版本中沒有PSCache功能，建議關閉掉。 5.5及以上版本有PSCache，建議開啓。
maxPoolPreparedStatementPerConnectionSize	10	100	要啓用PSCache，必須配置大於0，當大於0時， poolPreparedStatements自動觸發修改成true。 單個connnection獨享一個statement cache，也就是說maxOpenPreparedStatements是針對單個connection連接的

 

 

運行原理:

數據庫鏈接池在初始化的時候會建立initialSize個鏈接，當有數據庫操做時，會從池中取出一個鏈接。若是當前池中正在使用的鏈接數等於maxActive，則會等待一段時間，等待其餘操做釋放掉某一個鏈接，若是這個等待時間超過了maxWait，則會報錯；若是當前正在使用的鏈接數沒有達到maxActive，則判斷當前是否空閒鏈接，若是有則直接使用空閒鏈接，若是沒有則新創建一個鏈接。在鏈接使用完畢後，不是將其物理鏈接關閉，而是將其放入池中等待其餘操做複用。 同時鏈接池內部有機制判斷，若是當前的總的鏈接數少於miniIdle，則會創建新的空閒鏈接，以保證鏈接數獲得miniIdle。若是當前鏈接池中某個鏈接在空閒了timeBetweenEvictionRunsMillis時間後仍然沒有使用，則被物理性的關閉掉。有些數據庫鏈接的時候有超時限制（mysql鏈接在8小時後斷開），或者因爲網絡中斷等緣由，鏈接池的鏈接會出現失效的狀況，這時候設置一個testWhileIdle參數爲true，能夠保證鏈接池內部定時檢測鏈接的可用性，不可用的鏈接會被拋棄或者重建，最大狀況的保證從鏈接池中獲得的Connection對象是可用的。固然，爲了保證絕對的可用性，你也可使用testOnBorrow爲true（即在獲取Connection對象時檢測其可用性），不過這樣會影響性能。

若是要進行SQL監控，能夠加入如下代碼:

 

Log4j2Filter log4j2 = new Log4j2Filter();
log4j2.setResultSetLogEnabled(false);
log4j2.setStatementSqlPrettyFormat(false);
log4j2.setStatementExecutableSqlLogEnable(true);

log4j2.setDataSourceLogEnabled(false);
log4j2.setConnectionLogEnabled(false);
log4j2.setStatementLogEnabled(false);
log4j2.setResultSetLogEnabled(false);
ret.setProxyFilters(Arrays.asList(log4j2));

 

閒置檢測，建立鏈接，廢棄鏈接清理由這三線程管理

Daemon Thread [Abandoned connection cleanup thread] 
Daemon Thread [Druid-ConnectionPool-Create-1184124073] 
Daemon Thread [Druid-ConnectionPool-Destroy-1184124073] 

 

參考文章:數據庫鏈接池性能比對(hikari druid c3p0 dbcp jdbc)