redis之如何配置jedisPool參數

maxWait 連接池中連接用完時,新的請求等待時間,毫秒
timeBetweenEvictionRunsMillis timeBetweenEvictionRunsMillis和minEvictableIdleTimeMillis一起使用,每

timeBetweenEvictionRunsMillis毫秒秒檢查一次連接池中空閑的連接,把空閑時間超過minEvictableIdleTimeMillis毫秒的連接斷開,直到連接池中的連接數到minIdle為止

minEvictableIdleTimeMillis 連接池中連接可空閑的時間,毫秒

removeAbandoned true,false,是否清理removeAbandonedTimeout秒沒有使用的活動連接,清理后並沒有放回連接池
removeAbandonedTimeout 活動連接的最大空閑時間
logAbandoned true,false,連接池收回空閑的活動連接時是否打印消息


minEvictableIdleTimeMillis,removeAbandonedTimeout這兩個參數針對的連接對象不一樣,minEvictableIdleTimeMillis針對連接池中的連接對象,removeAbandonedTimeout針對未被close的活動連接.

 

在配置時，主要難以理解的主要有：removeAbandoned 、logAbandoned、removeAbandonedTimeout、maxWait這四個參數，設置了rmoveAbandoned=true那么在getNumActive()快要到getMaxActive()的時候，系統會進行無效的Connection的回收，回收的Connection為removeAbandonedTimeout(默認300秒)中設置的秒數后沒有使用的Connection，激活回收機制好像是getNumActive()=getMaxActive()-2。 :) 　　logAbandoned=true的話，將會在回收事件后，在log中打印出回收Connection的錯誤信息，包括在哪個地方用了Connection卻忘記關閉了，在調試的時候很有用。
　　在這里私人建議maxWait的時間不要設得太長，maxWait如果設置太長那么客戶端會等待很久才激發回收事件

http://blog.csdn.net/feiyu8607/article/details/6551991

 

validationQuery

DBCP提供的validationQuery參數進行連接的預檢測，它會在與連接池交互的過程中加入一些鈎子，定點執行validationQuery指定的SQL語句，如果SQL語句執行成功，表示此連接有效，分配給應用，如果執行失敗，則丟棄此連接，這種方法還能應對網絡故障等問題造成的MySQL連接失效問題。其他的一些方法，比如空閑連接檢測，樂觀獲取連接等方式，都無法保證完全對應用透明，應用還是能感知到數據庫操作失敗。

 

 

minEvictableIdleTimeMillis

 

 

連接池中連接，在時間段內一直空閑， 被逐出連接池的時間

 

 

 

timeBetweenEvictionRunsMillis

在構造GenericObjectPool [BasicDataSource在其createDataSource () 方法中也會使用GenericObjectPool]時，會生成一個內嵌類Evictor，實現自Runnable接口。如果timeBetweenEvictionRunsMillis大於0，每過 timeBetweenEvictionRunsMillis毫秒Evictor會調用evict()方法，檢查連接池中的連接的閑置時間是否大於 minEvictableIdleTimeMillis毫秒（_minEvictableIdleTimeMillis小於等於0時則忽略，默認為30分鍾），是則銷毀此對象，然后調用ensureMinIdle方法檢查確保池中對象個數不小於_minIdle。如果連接池的連接數小於最小空閑連接數，則創建數據庫連接，同時檢查連接池的連接是否小於maxIdle，是則把剛創建的連接放入連接池中，否則銷毀此對象。

http://blog.csdn.net/qyy333/article/details/17920051

 

https://github.com/xetorthio/jedis/issues/937

 

redis之如何配置jedisPool參數

 

JedisPool的配置參數很大程度上依賴於實際應用需求、軟硬件能力，JedisPool的配置參數大部分是由JedisPoolConfig的對應項來賦值的。

 

maxActive：控制一個pool可分配多少個jedis實例，通過pool.getResource()來獲取；如果賦值為-1，則表示不限制；如果pool已經分配了maxActive個jedis實例，則此時pool的狀態就成exhausted了，在JedisPoolConfig

maxIdle：控制一個pool最多有多少個狀態為idle的jedis實例；

whenExhaustedAction：表示當pool中的jedis實例都被allocated完時，pool要采取的操作；默認有三種WHEN_EXHAUSTED_FAIL（表示無jedis實例時，直接拋出NoSuchElementException）、WHEN_EXHAUSTED_BLOCK（則表示阻塞住，或者達到maxWait時拋出JedisConnectionException）、WHEN_EXHAUSTED_GROW（則表示新建一個jedis實例，也就說設置的maxActive無用）；

maxWait：表示當borrow一個jedis實例時，最大的等待時間，如果超過等待時間，則直接拋出JedisConnectionException；

testOnBorrow：在borrow一個jedis實例時，是否提前進行alidate操作；如果為true，則得到的jedis實例均是可用的；

testOnReturn：在return給pool時，是否提前進行validate操作；

testWhileIdle：如果為true，表示有一個idle object evitor線程對idle object進行掃描，如果validate失敗，此object會被從pool中drop掉；這一項只有在timeBetweenEvictionRunsMillis大於0時才有意義；

timeBetweenEvictionRunsMillis：表示idle object evitor兩次掃描之間要sleep的毫秒數；

numTestsPerEvictionRun：表示idle object evitor每次掃描的最多的對象數；

minEvictableIdleTimeMillis：表示一個對象至少停留在idle狀態的最短時間，然后才能被idle object evitor掃描並驅逐；這一項只有在timeBetweenEvictionRunsMillis大於0時才有意義；

softMinEvictableIdleTimeMillis：在minEvictableIdleTimeMillis基礎上，加入了至少minIdle個對象已經在pool里面了。如果為-1，evicted不會根據idle time驅逐任何對象。如果minEvictableIdleTimeMillis>0，則此項設置無意義，且只有在timeBetweenEvictionRunsMillis大於0時才有意義；

lifo：borrowObject返回對象時，是采用DEFAULT_LIFO（last in first out，即類似cache的最頻繁使用隊列），如果為False，則表示FIFO隊列；

 

其中JedisPoolConfig對一些參數的默認設置如下：

testWhileIdle=true

minEvictableIdleTimeMills=60000

timeBetweenEvictionRunsMillis=30000

numTestsPerEvictionRun=-1