【redis】常見JedisConnectionException異常分析最近項(xiàng)目開發(fā)中用到了Redis,選擇了官網(wǎng)推薦的javaclientJedis。

Redis常用命令學(xué)習(xí)：http://redis.io/commands

Redis官方推薦Java客戶端Jedis（包含了所有Redis命令的實(shí)現(xiàn)）：/xetorthio/jedis

Jedis使用過程中最常見異常JedisConnectionException有時(shí)確實(shí)給我們帶來了很多困惑，這個(gè)異常通常出現(xiàn)在兩個(gè)使場景。

一、當(dāng)我們執(zhí)行如下JedisPool類實(shí)例的getResource()時(shí)拋出can'tgetaresource異常。異常代碼如下：redis.clients.jedis.exceptions.JedisConnectionException:Couldnotgetaresourcefromthepoolatredis.clients.util.Pool.getResource(Pool.java:22)分析：redis.clients.util.Pool.getResource會從JedisPool實(shí)例池中返回一個(gè)可用的redis連接。分析源碼可知JedisPoolextendsredis.clients.util.Pool<Jedis>

.而Pool<T>是通過commons-pool開源工具包中的mons.pool.impl.GenericObjectPool來實(shí)現(xiàn)對Jedis實(shí)例的管理的。所以我們分析一下GenericObjectPool或許能找到答案。首先看一下common-pool的api:/pool/apidocs/index.html?org/apache/commons/pool/impl/GenericObjectPool.html。

其中三個(gè)重要個(gè)幾個(gè)屬性是：

MaxActive:可用連接實(shí)例的最大數(shù)目，為負(fù)值時(shí)沒有限制。

MaxIdle:空閑連接實(shí)例的最大數(shù)目，為負(fù)值時(shí)沒有限制。Idle的實(shí)例在使用前，通常會通過mons.pool.BasePoolableObjectFactory<T>的activateObject()方法使其變得可用。

MaxWait:等待可用連接的最大數(shù)目，單位毫秒（millionseconds）。

（注:pool.getResource()方法實(shí)際調(diào)用的GenericObjectPool類borrowObject()方法，該方法會根據(jù)MaxWait變量值在沒有可用連接（idle/active)時(shí)阻塞等待知道超時(shí)，具體含義參看api。）也就是說當(dāng)連接池中沒有active/idle的連接時(shí)，會等待maxWait時(shí)間，如果等待超時(shí)還沒有可用連接，則拋出Couldnotgetaresourcefromthepool異常。所以為避免這樣的錯誤，我們應(yīng)該根據(jù)程序?qū)嶋H情況合理設(shè)置這三個(gè)參數(shù)的值，同時(shí)在我們獲取一個(gè)連接的程序方法中也應(yīng)該合理的處理這個(gè)異常，當(dāng)沒有連接可用時(shí)，等待一段時(shí)間再獲取也許是個(gè)比較好的選擇。二、當(dāng)我們獲取連接后對redis進(jìn)行操作時(shí)，拋出redis.clients.jedis.exceptions.JedisConnectionException:.SocketTimeoutException:Readtimedout異常。異常代碼如下：redis.clients.jedis.exceptions.JedisConnectionException:.SocketTimeoutException:Readtimedoutatredis.clients.jedis.Pcess(Protocol.java:79)

atredis.clients.jedis.Protocol.read(Protocol.java:131)

atredis.clients.jedis.Connection.getIntegerReply(Connection.java:188)

atredis.clients.jedis.Jedis.sismember(Jedis.java:1266)這是一個(gè)比較麻煩的異常，困擾了我一天的時(shí)間。我們都知道Redis是對內(nèi)存進(jìn)行操作，速度應(yīng)該都在毫秒級，這是我們通常的認(rèn)識，所以當(dāng)對Redis操作出現(xiàn)幾秒的超時(shí)時(shí)間，你能想象嗎？

我們還是先分析一下Jedis的源代碼吧，以sadd操作為例：publicLongsadd(finalStringkey,finalString...members){checkIsInMulti();client.sadd(key,members);returnclient.getIntegerReply();}client是redis.clients.jedis.Client.java的實(shí)例，繼承關(guān)系如下：

publicclassClientextendsBinaryClientimplementsCommands；publicclassBinaryClientextendsConnection；Connection包裝了對Redisserver的socket操作，命令寫操作通過socket.getOutputStream()輸出流將命令信息發(fā)送到redisserver，當(dāng)寫完命令后要通過socket.getInputStream()的到的輸入流將

命令執(zhí)行結(jié)果返回，這中間必然會有一個(gè)命令執(zhí)行到結(jié)果返回的延時(shí)時(shí)間，這就是一個(gè)Jedis調(diào)用redis命令操作所用的時(shí)間。需要說明的是，Redisserver是單線程執(zhí)行所有連接發(fā)送過來的命令的，也就是說不管并發(fā)中有多少個(gè)client在發(fā)送命令，redis-server端是單線程處理的，并按照默認(rèn)的FIFO方式處理請求，這個(gè)可在redis.conf配置文件中配置。關(guān)于redisserver的詳細(xì)運(yùn)行機(jī)制參見：http://redis.io/documentation所以client.sadd(key,members);調(diào)用完后只是將命令信息發(fā)送到了redisserver端，具體有沒有執(zhí)行要看redisserver的負(fù)載情況。然后，通過client.getIntegerReply();等待（timeout)返回結(jié)果。

Connection初始化socket時(shí)有多種選擇，其中設(shè)置sockettimeout的方法如下：publicvoidrollbackTimeout(){

try{

socket.setSoTimeout(timeout);

socket.setKeepAlive(false);

}catch(SocketExceptionex){

thrownewJedisException(ex);

}

}由redis.clients.jedis.Protocol.DEFAULT_TIMEOUT=2000我們知道默認(rèn)的超時(shí)時(shí)間是2秒，這個(gè)時(shí)間相對于redis操作內(nèi)存毫秒級的速度來說已經(jīng)很長，那我們?yōu)槭裁催€會遇到

.SocketTimeoutException:Readtimedout異常呢？redis操作內(nèi)存雖然平均毫秒級的，但當(dāng)數(shù)據(jù)量很大時(shí)未必都如此快速。在我的開發(fā)過程中就遇到過一個(gè)集合到了千萬級數(shù)據(jù)量，一次操作超時(shí)時(shí)間在秒級是很正常的，而且機(jī)器性能很好的情況下已經(jīng)如此，更何況我們本機(jī)開發(fā)的機(jī)器相對于生產(chǎn)服務(wù)器來說速度會更慢了。所以在初始化JedisPool時(shí)應(yīng)該根據(jù)實(shí)際情況通過redis.clients.jedis.JedisPoolConfig合理設(shè)置連接池參數(shù)，通過edisPool構(gòu)造方法，合理設(shè)置s