快捷導(dǎo)航

關(guān)于數(shù)據(jù)庫(kù)連接池Druid使用說(shuō)明

更新時(shí)間：2017年10月01日 13:52:11 作者：流子

這篇文章主要介紹了關(guān)于數(shù)據(jù)庫(kù)連接池Druid使用說(shuō)明，涉及Druid 參數(shù)和運(yùn)行原理等等相關(guān)內(nèi)容，小編覺(jué)得挺不錯(cuò)的，在這里給大家分享一下。

根據(jù)綜合性能，可靠性，穩(wěn)定性，擴(kuò)展性，易用性等因素替換成最優(yōu)的數(shù)據(jù)庫(kù)連接池。

Druid:druid-1.0.29

數(shù)據(jù)庫(kù) Mysql.5.6.17

替換目標(biāo):替換掉C3P0,用druid來(lái)替換

替換原因:

1、性能方面 hikariCP>druid>tomcat-jdbc>dbcp>c3p0 。hikariCP的高性能得益于最大限度的避免鎖競(jìng)爭(zhēng)。

2、druid功能最為全面，sql攔截等功能，統(tǒng)計(jì)數(shù)據(jù)較為全面，具有良好的擴(kuò)展性。

3、綜合性能，擴(kuò)展性等方面，可考慮使用druid或者h(yuǎn)ikariCP連接池，比較方便對(duì)jdbc接口進(jìn)行監(jiān)控跟蹤等。

4、可開(kāi)啟prepareStatement緩存，對(duì)性能會(huì)有大概20%的提升。

psCache是connection私有的，所以不存在線程競(jìng)爭(zhēng)的問(wèn)題，開(kāi)啟pscache不會(huì)存在競(jìng)爭(zhēng)的性能損耗。

psCache的key為prepare執(zhí)行的sql和catalog等，value對(duì)應(yīng)的為prepareStatement對(duì)象。開(kāi)啟緩存主要是減少了解析sql的開(kāi)銷(xiāo)。

5、3p0歷史悠久，代碼及其復(fù)雜，不利于維護(hù)。并且存在deadlock的潛在風(fēng)險(xiǎn)。

6、Druid可以打印SQL，慢查詢(xún)方面的日志

Druid 參數(shù)

配置參數(shù)	缺省值	游戲服設(shè)置的值	參數(shù)說(shuō)明
initialSize	0	4	初始化連接數(shù)量
minIdle	0	4	最小空閑連接數(shù)
maxActive	8	8	最大并發(fā)連接數(shù)
maxWait	-1L	60000	獲取連接時(shí)最大等待時(shí)間，單位毫秒。配置了maxWait之后，缺省啟用公平鎖，并發(fā)效率會(huì)有所下降，如果需要可以通過(guò)配置useUnfairLock屬性為true使用非公平鎖。
timeBetweenEvictionRunsMillis	60000	60000	配置間隔多久才進(jìn)行一次檢測(cè)，檢測(cè)需要關(guān)閉的空閑連接，單位是毫秒 Destroy線程會(huì)檢測(cè)連接的間隔時(shí)間
minEvictableIdleTimeMillis	1800000	1800000	配置一個(gè)連接在池中最小生存的時(shí)間，單位是毫秒
validationQuery	null	select 1	用來(lái)檢測(cè)連接是否有效的sql，要求是一個(gè)查詢(xún)語(yǔ)句
testOnBorrow	FALSE	FALSE	申請(qǐng)連接時(shí)執(zhí)行validationQuery檢測(cè)連接是否有效，做了這個(gè)配置會(huì)降低性能。
testOnReturn	FALSE	FALSE	歸還連接時(shí)執(zhí)行validationQuery檢測(cè)連接是否有效，做了這個(gè)配置會(huì)降低性能
testWhileIdle	TRUE	TRUE	建議配置為true，不影響性能，并且保證安全性。申請(qǐng)連接的時(shí)候檢測(cè)，如果空閑時(shí)間大于 timeBetweenEvictionRunsMillis，執(zhí)行validationQuery檢測(cè)連接是否有效。
poolPreparedStatements	FALSE	TRUE	false 是否緩存preparedStatement，也就是PSCache。 PSCache對(duì)支持游標(biāo)的數(shù)據(jù)庫(kù)性能提升巨大，比如說(shuō)oracle。在mysql5.5以下的版本中沒(méi)有PSCache功能，建議關(guān)閉掉。 5.5及以上版本有PSCache，建議開(kāi)啟。
maxPoolPreparedStatementPerConnectionSize	10	100	要啟用PSCache，必須配置大于0，當(dāng)大于0時(shí)， poolPreparedStatements自動(dòng)觸發(fā)修改為true。單個(gè)connnection獨(dú)享一個(gè)statement cache，也就是說(shuō)maxOpenPreparedStatements是針對(duì)單個(gè)connection鏈接的

運(yùn)行原理:

數(shù)據(jù)庫(kù)連接池在初始化的時(shí)候會(huì)創(chuàng)建initialSize個(gè)連接，當(dāng)有數(shù)據(jù)庫(kù)操作時(shí)，會(huì)從池中取出一個(gè)連接。如果當(dāng)前池中正在使用的連接數(shù)等于maxActive，則會(huì)等待一段時(shí)間，等待其他操作釋放掉某一個(gè)連接，如果這個(gè)等待時(shí)間超過(guò)了maxWait，則會(huì)報(bào)錯(cuò)；如果當(dāng)前正在使用的連接數(shù)沒(méi)有達(dá)到maxActive，則判斷當(dāng)前是否空閑連接，如果有則直接使用空閑連接，如果沒(méi)有則新建立一個(gè)連接。在連接使用完畢后，不是將其物理連接關(guān)閉，而是將其放入池中等待其他操作復(fù)用。同時(shí)連接池內(nèi)部有機(jī)制判斷，如果當(dāng)前的總的連接數(shù)少于miniIdle，則會(huì)建立新的空閑連接，以保證連接數(shù)得到miniIdle。如果當(dāng)前連接池中某個(gè)連接在空閑了timeBetweenEvictionRunsMillis時(shí)間后仍然沒(méi)有使用，則被物理性的關(guān)閉掉。有些數(shù)據(jù)庫(kù)連接的時(shí)候有超時(shí)限制（mysql連接在8小時(shí)后斷開(kāi)），或者由于網(wǎng)絡(luò)中斷等原因，連接池的連接會(huì)出現(xiàn)失效的情況，這時(shí)候設(shè)置一個(gè)testWhileIdle參數(shù)為true，可以保證連接池內(nèi)部定時(shí)檢測(cè)連接的可用性，不可用的連接會(huì)被拋棄或者重建，最大情況的保證從連接池中得到的Connection對(duì)象是可用的。當(dāng)然，為了保證絕對(duì)的可用性，你也可以使用testOnBorrow為true（即在獲取Connection對(duì)象時(shí)檢測(cè)其可用性），不過(guò)這樣會(huì)影響性能。

如果要進(jìn)行SQL監(jiān)控，可以加入以下代碼:

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));

閑置檢測(cè)，創(chuàng)建連接，廢棄連接清理由這三線程管理

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

總結(jié)

以上就是本文關(guān)于數(shù)據(jù)庫(kù)連接池Druid使用說(shuō)明的全部?jī)?nèi)容，希望對(duì)大家有所幫助。感興趣的朋友可以參閱：MySQL prepare原理詳解等及其他相關(guān)專(zhuān)題，有什么問(wèn)題可以隨時(shí)留言，小編會(huì)及時(shí)回復(fù)大家的。

您可能感興趣的文章: