在Redis客戶端的使用過程中，無論是客戶端使用不當或者Redis服務端出現問題，客戶端會反應出一些異常，下面分析一下Jedis使用過程中常見的異常情況：

一.無法從連線池獲取到連線

JedisPool中的Jedis物件個數是有限的，預設是8個。這裡假設使用的預設配置，如果有8個Jedis物件被佔用，並且沒有歸還，如果呼叫者還要從JedisPool中借用Jedis，就需要進行等待(例如設定了maxWaitMillis>0)，如果在maxWaitMillis時間內仍然無法獲取到Jedis物件就會丟擲如下異常。

1. redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool  
2.     …  
3. Caused by: java.util.NoSuchElementException: Timeout waiting for idle object  
4.     at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:449)  

還有一種情況，就是設定了blockWhenExhausted=false，那麼呼叫者發現池子中沒有資源時，會立即丟擲異常不進行等待，下面的異常就是blockWhenExhausted=false時的效果。

1. redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool  
2.     …  
3. Caused by: java.util.NoSuchElementException: Pool exhausted  
4.     at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:464)  

對於這個問題，需要重點討論的是為什麼連線池沒有資源了，造成沒有資源的可能的原因非常多

• 1.客戶端：高併發下連線池設定過小，出現供不應求，所以會出現上面的錯誤，但是正常情況下只要比預設的最大連線數(8個)多一些即可，因為正常情況下JedisPool以及Jedis的處理效率足夠高。

• 2.客戶端：沒有正確使用連線池，比如沒有進行釋放，例如下面程式碼所示：
  定義JedisPool，使用預設的連線池配置。

1. GenericObjectPoolConfig poolConfig = new GenericObjectPoolConfig();  
2. JedisPool jedisPool = new JedisPool(poolConfig, "127.0.0.1", 6379);  
3. //向JedisPool借用8次連線，但是沒有執行歸還操作。  
4. for (int i = 0; i < 8; i++) {  
5.     Jedis jedis = null;  
6.     try {  
7.     jedis = jedisPool.getResource();  
8.     jedis.ping();  
9.     } catch (Exception e) {  
10.     e.printStackTrace();  
11.     }  
12. }  

當呼叫者再向連線池借用Jedis時(如下操作)，就會丟擲異常:

1. jedisPool.getResource().ping();  

• 3.客戶端：存在慢查詢操作，這些慢查詢持有的Jedis物件歸還速度會比較慢，造成池子滿了。
• 4.服務端：客戶端是正常的，但是Redis服務端由於一些原因造成了客戶端命令執行過程的阻塞，也會使得客戶端丟擲這種異常。
  可以看到造成這個異常的原因是多個方面的，不要被異常的表象所迷惑，而且並不存在通用的解決方案，開發和運維只能不斷加強對於Redis的理解，順藤摸瓜逐漸找到問題所在。

二、 客戶端讀寫超時

Jedis在呼叫Redis時，如果出現了讀寫超時後，會出現下面的異常：

1. redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketTimeoutException: Read timed out  

• 讀寫超時設定的過短。
• 命令本身就比較慢。
• 客戶端與服務端網路不正常。
• Redis自身發生阻塞。

三 客戶端連線超時

Jedis在呼叫Redis時，如果出現了讀寫超時後，會出現下面的異常：

1. redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketTimeoutException: connect timed out  

• 連線超時設定的過短。
• Redis發生阻塞，造成tcp-backlog已滿，造成新的連線失敗。
• 客戶端與服務端網路不正常。

四、客戶端緩衝區異常

Jedis在呼叫Redis時，如果出現客戶端資料流異常，會出現下面的異常。

1. redis.clients.jedis.exceptions.JedisConnectionException: Unexpected end of stream.  

• 1.輸出緩衝區滿。例如將普通客戶端的輸出緩衝區設定為1M 1M 60：

1. config set client-output-buffer-limit "normal 1048576 1048576 60 slave 268435456 67108864 60 pubsub 33554432 8388608 60"  

如果使用get命令獲取一個bigkey(例如3M)，就會出現這個異常。

• 2.長時間閒置連線被服務端主動斷開，可以查詢timeout配置的設定以及自身連線池配置是否需要做空閒檢測。
• 3.不正常併發讀寫：Jedis物件同時被多個執行緒併發操作，可能會出現上述異常。

五、Lua指令碼正在執行

如果Redis當前正在執行Lua指令碼，並且超過了lua-time-limit，此時Jedis呼叫Redis時，會收到下面的異常。對於如何處理這類問題(Lua lua-time-limit配置之前章節已經介紹了)

1. redis.clients.jedis.exceptions.JedisDataException: BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE  

六、Redis正在載入持久化檔案

Jedis呼叫Redis時，如果Redis正在載入持久化檔案，那麼會收到下面的異常。

1. redis.clients.jedis.exceptions.JedisDataException: LOADING Redis is loading the dataset in memory  

七、Redis使用的記憶體超過maxmemory配置

Jedis呼叫Redis執行寫操作時，如果Redis的使用記憶體大於maxmemory的設定，會收到下面的異常，此時應該調整maxmemory並找到造成記憶體增長的原因(maxmemory之前章節已經介紹了)

1. redis.clients.jedis.exceptions.JedisDataException: OOM command not allowed when used memory > 'maxmemory'.  

八、客戶端連線數過大

如果客戶端連線數超過了maxclients，新申請的連線就會出現如下異常：

1. redis.clients.jedis.exceptions.JedisDataException: ERR max number of clients reached  

此時新的客戶端連線執行任何命令，返回結果都是如下： 

1. 127.0.0.1:6379> get hello  
2. (error) ERR max number of clients reached  

•  1.客戶端：如果maxclients引數不是很小的話，應用方的客戶端連線數基本不會超過maxclients，通常來看是由於應用方對於Redis客戶端使用不當造成的。此時如果應用方是分散式結構的話，可以通過下線部分應用節點(例如佔用連線較多的節點)，使得Redis的連線數先降下來。從而讓絕大部分節點可以正常執行，此時在再通過查詢程式bug或者調整maxclients進行問題的修復。這個問題可能會比較棘手，因為此時無法執行Redis命令，一般來說可以從兩個方面進行著手。
• 2.服務端：如果此時客戶端無法處理，而當前Redis為高可用模式(例如Redis Sentinel和Redis Cluster)，可以考慮將當前Redis做故障轉移。