Jedis出現(xiàn)connection timeout問題解決方法(JedisPool連接池使用實例)
今天發(fā)現(xiàn)Jedis 默認的連接方式 jedis=new Jedis(“l(fā)ocalhost”,6379),老是發(fā)生connection timeout. 后來發(fā)現(xiàn)jedis類包還有一種可以設置最大連接時間的方法。
1->獲取Jedis實例需要從JedisPool中獲?。?BR>2->用完Jedis實例需要還給JedisPool;
3->如果Jedis在使用過程中出錯,則也需要還給JedisPool;
代碼如下
JedisPoolConfig config = new JedisPoolConfig();
config.setMaxActive(100);
config.setMaxIdle(20);
config.setMaxWait(1000l);
JedisPool pool;
pool = new JedisPool(config, "2xx.xx.xx.14", 6379);
boolean borrowOrOprSuccess = true;
try {
jedis = pool.getResource();
// do redis opt by instance
} catch (JedisConnectionException e) {
borrowOrOprSuccess = false;
if (jedis != null)
pool.returnBrokenResource(jedis);
} finally {
if (borrowOrOprSuccess)
pool.returnResource(jedis);
}
jedis = pool.getResource();
JedisPool依賴apache類包
commons-pool-1.5.6.jar
1->雖然拋出JedisConnectionException,但實際上有兩類錯誤,一類是pool.getReource(),得不到可用的jedis實例;另一類是jedis.set/get時出錯也會拋出這個Exception;為了實現(xiàn)區(qū)分,所以根據(jù)instance是否為null來實現(xiàn),如果為空就證明instance根本就沒初始化,也就不用return給pool;如果instance不為null,則證明是需要返還給pool的;
2->在instance出錯時,也要調(diào)用returnBrokenResource返還給pool,否則下次通過getResource得到的instance的緩沖區(qū)可能還存在數(shù)據(jù),出現(xiàn)問題!
JedisPool的配置參數(shù)很大程度上依賴于實際應用需求、軟硬件能力。以前沒用過commons-pool,所以這次花了一整間專門看這些參數(shù)的含義。。。JedisPool的配置參數(shù)大部分是由JedisPoolConfig的對應項來賦值的。
maxActive:控制一個pool可分配多少個jedis實例,通過pool.getResource()來獲?。蝗绻x值為-1,則表示不限制;如果pool已經(jīng)分配了maxActive個jedis實例,則此時pool的狀態(tài)就成exhausted了,在JedisPoolConfig
maxIdle:控制一個pool最多有多少個狀態(tài)為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的毫秒數(shù);
numTestsPerEvictionRun:表示idle object evitor每次掃描的最多的對象數(shù);
minEvictableIdleTimeMillis:表示一個對象至少停留在idle狀態(tài)的最短時間,然后才能被idle object evitor掃描并驅(qū)逐;這一項只有在timeBetweenEvictionRunsMillis大于0時才有意義;
softMinEvictableIdleTimeMillis:在minEvictableIdleTimeMillis基礎上,加入了至少minIdle個對象已經(jīng)在pool里面了。如果為-1,evicted不會根據(jù)idle time驅(qū)逐任何對象。如果minEvictableIdleTimeMillis>0,則此項設置無意義,且只有在timeBetweenEvictionRunsMillis大于0時才有意義;
lifo:borrowObject返回對象時,是采用DEFAULT_LIFO(last in first out,即類似cache的最頻繁使用隊列),如果為False,則表示FIFO隊列;
其中JedisPoolConfig對一些參數(shù)的默認設置如下:
testWhileIdle=true
minEvictableIdleTimeMills=60000
timeBetweenEvictionRunsMillis=30000
numTestsPerEvictionRun=-1
相關文章
踩坑批量更新sql報錯,實際sql能夠正常執(zhí)行的問題
在項目工程遷移過程中,遇到了一個批量更新接口在新工程中報錯的問題,通過分析,排除了代碼錯誤的可能,最終發(fā)現(xiàn)是由于數(shù)據(jù)庫連接配置不當導致的,在jdbc連接字符串中加入allowMultiQueries=true參數(shù)后,問題得以解決,這個參數(shù)的作用是允許SQL批量執(zhí)行2022-12-12
詳解Java的Hibernate框架中的set映射集與SortedSet映射
這篇文章主要介紹了詳解Java的Hibernate框架中的set映射集與SortedSet映射,Hibernate是Java的SSH三大web開發(fā)框架之一,需要的朋友可以參考下2015-12-12

