Jedis Unexpected end of stream & java.net.SocketException: Broken pipe問題解決思路

筆者一直維護的穩定基礎服務測試環境不穩定了，這能忍！盤他，雖然不必定能徹底盤的了。

背景：

hrexternal 基礎服務對外提供公司員工獲取的多個接口，不少接口訪問頻率比較高，加了緩存，使用的是redis，可是redis最近2個月測試環境已經出問題了，時不時的報錯，以前流程平臺也報過錯，只不過是隨機的，不是必現的。當時也是沒有具體緣由，只是將底層的redis實例換掉了。而後就行了，這個服務呢因爲歷史緣由還有不少其餘服務是用的同一個redis實例，換的話須要好幾個服務一塊兒換，保障穩定性。
此次出現的問題更嚴重，由於每隔幾分鐘就會報錯，get報錯，put也會報錯。因此就跟進排查了下。
Redis版本：3.0.7
Jedis版本：2.8.0
異常以下：

這倆異常不常常遇到，可是一旦遇到確定是比較麻煩的。
筆者也是百度了不少，不少，從下面的連接中瞭解到一些信息：

https://blog.csdn.net/aubdiy/article/details/53511410

也是按照上面的思路進行排查：

1.找DBA幫忙看redis是否有改動配置，沒有

2.看超時時間，客戶端沒有單獨設置鏈接參數，默認超時時間應該是2秒。

3.多是網絡問題。可是實際上不是。

4.根據jedis  github上面的issues討論內容發現具體緣由也沒有說出來，可是出現這個問題的人確實挺多的。解決的人基本上都加了Jedis的鏈接配置了，恰好咱們的沒有加，還有可能解決。

這裏就揭開了針對於Jedis配置的一場探索之路。
首先看這個hrexternal服務的jedis初始化代碼：

/**
     *  初始化資源池
     */
    static {
        try {
            if (jedisSentinelPool ==null) {
              logger.info("init JedisSentinelPool is start....");
                logger.info("redis_ip1:"+RedisConfig.redis_ip1+",redis_port1:"+RedisConfig.redis_port1);
                logger.info("redis_ip2:"+RedisConfig.redis_ip2+",redis_ip2:"+RedisConfig.redis_port2);
                logger.info("redis_ip3:"+RedisConfig.redis_ip3+",redis_ip2:"+RedisConfig.redis_port3);
              Set<String> sentinels = new HashSet<String>();
              sentinels.add(new HostAndPort(RedisConfig.redis_ip1, Integer.parseInt(RedisConfig.redis_port1)).toString());
              sentinels.add(new HostAndPort(RedisConfig.redis_ip2, Integer.parseInt(RedisConfig.redis_port2)).toString());
              sentinels.add(new HostAndPort(RedisConfig.redis_ip3, Integer.parseInt(RedisConfig.redis_port3)).toString());
              jedisSentinelPool = new JedisSentinelPool(RedisConfig.master, sentinels);
              logger.info(" init JedisSentinelPool is end....");
            }
        }catch(Exception e){
              logger.error("---->init JedisSentinelPool was failed,the msg is " + e.getMessage(), e);
        }
    }
    

    /**
     * 獲取資源
     * @return
     * @throws Exception
     */
    public static synchronized Jedis getJedis() throws Exception {
        try {
            if(jedisSentinelPool != null) {
                Jedis e = jedisSentinelPool.getResource();
                return e;
            } else {
                return null;
            }
        } catch (Exception e) {
            e.printStackTrace();
            logger.error(e);
            return null;
        }
    }

使用的是Jedis哨兵模式進行Jedis初始化，同時使用Jedis鏈接池。出現上面的異常不少緣由都跟鏈接池的鏈接有關。所以有必要分析一下Jedis的鏈接池和鏈接配置參數，以下圖是Jedis鏈接配置參數和Jedis的鏈接池對象的類圖：

其中只有GenericObjectPoolConfig，BaseObjectPoolConfig不是Jedis中的類，其餘都是。這倆類是jedis依賴的另外一個jar包：

<dependency>
            <groupId>org.apache.commons</groupId>
            <artifactId>commons-pool2</artifactId>
            <version>2.6.2</version>
            <type>jar</type>
            <scope>compile</scope>
        </dependency>

這個包是否是看着既熟悉又陌生。這個居然是java對象池池化技術的一個實現，相關文章以下：

http://www.javashuo.com/article/p-exmsbwzy-gd.html

固然本文的分析內容也包括這個，其中Jedis的一些配置參數也跟這個池化對象配置有關。

下面是我整理的一個配置參數介紹：

1. maxTotal:程序容許建立資源的最大數量；默認值 -1，-1 表明無數量限制（int類型）
2. blockWhenExhausted：當資源耗盡時，是否阻塞等待獲取資源；默認值 true
3. maxWaitMillis： 獲取資源時的等待時間，單位毫秒。當blockWhenExhausted 配置爲 true 時，此值有效。 -1 表明無時間限制,一直阻塞直到有可用的資源。（long類型）
4. testOnBorrow： 否在從池中取出鏈接前進行檢驗,若是檢驗失敗,則從池中去除鏈接並嘗試取出另外一個；默認值 false ，當設置爲true時，調用 factory.validateObject() 方法
5. testOnCreate 建立連接的時候進行連接有效性檢查； 默認值 false，當設置爲true時，調用 factory.validateObject() 方法（備註：若是 testOnBorrow 或者 testOnCreate 中有一個 配置 爲 true 時，就調用 factory.validateObject() ）
6. lifo 資源的存取數據結構，默認值 true，true 資源按照棧結構存取，false 資源按照隊列結構存取
7. fairness 當從池中獲取資源或者將資源還回池中時 是否使用 java.util.concurrent.locks.ReentrantLock.ReentrantLock 的公平鎖機制。 默認值 false， true 使用公平鎖，false 不使用公平鎖，
8. timeBetweenEvictionRunsMillis 回收資源線程的執行週期，單位毫秒。默認值 -1 ，-1 表示不啓用線程回收資源。（long類型）
9. evictionPolicyClassName 資源回收策略， 默認值org.apache.commons.pool2.impl.DefaultEvictionPolicy（String類型）
10. minEvictableIdleTimeMillis 鏈接在池中保持空閒而不被空閒鏈接回收器線程(若是有)回收的最小時間值； 默認值 1800000，單位 毫秒（long類型 ）
11. softMinEvictableIdleTimeMillis 軟資源最小空閒時間， 默認值 -1 ，單位 毫秒，（long類型 ）（備註，這個兩個參數，在資源回收策略中，會使用到）
12. maxIdle 最大空閒資源數，默認值 8 （int類型）
13. minIdle 最小空閒資源數，默認值 0 （int類型 ）
14. testWhileIdle 指明鏈接是否被空閒鏈接回收器(若是有)進行檢驗.若是檢測失敗,則鏈接將被從池中去除；默認值 false； 設置爲 true 時，當回收策略返回false時，則 調用 factory.activateObject()和factory.validateObject()
15. testOnReturn 默認值 false； 設置爲 true 時，當將資源返還個資源池時候，驗證資源的有效性，調用 factory.validateObject()方法，若是無效，則調用 factory.destroyObject()方法
16. numTestsPerEvictionRun 資源回收線程執行一次回收操做，回收資源的數量。默認值 3， （int類型）。
    備註：當 設置爲0時，不回收資源。
    設置爲 小於0時，回收資源的個數爲 (int)Math.ceil( 池中空閒資源個數 / Math.abs(numTestsPerEvictionRun) );設置爲 大於0時，回收資源的個數爲 Math.min( numTestsPerEvictionRun,池中空閒的資源個數 );

因爲上面代碼的配置是使用默認的參數，也就是說當連接出現問題的時候你是不知道是客戶端出的問題仍是服務端出的問題，跟DBA確認了一些服務端的參數：
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 512mb 128mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
timeout 60 配置的60s。
因爲服務端沒有動配置，客戶端沒有動配置，也沒有動代碼。封裝Jedis操做的每一個API都檢查了，最後都有finally代碼塊保證jedis用完會close.
不存在連接泄露問題。那爲啥上面的錯會發生？爲啥穩定運行了很長時間最近才報錯。
固然幾個可能的方向

1. 這個Redis實例被不少服務共享，致使數據錯亂或者Redis連接有問題。
2. Jedis配置問題
3. 版本問題。
   當我設置了jedis連接池參數以後就不會出現上面的異常了，配置代碼以下：

JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
                jedisPoolConfig.setTestOnBorrow(true);
                jedisPoolConfig.setTestOnReturn(true);
                jedisPoolConfig.setTestOnCreate(true);
                jedisPoolConfig.setMaxTotal(50);
                jedisPoolConfig.setMaxIdle(10);
                jedisPoolConfig.setMinIdle(1);
                jedisPoolConfig.setMaxWaitMillis(3000);
jedisSentinelPool = new JedisSentinelPool(RedisConfig.master, sentinels,jedisPoolConfig);

部署完以後，發現異常再也不出現。
雖然具體緣由沒有找到可是經過jedis開源代碼和issues能夠獲得一些結論：
https://github.com/xetorthio/jedis/issues/932
https://blog.csdn.net/SakuraInLuoJia/article/details/89874287

也就是說有2點建議

1. 不建議用Jedis默認的連接池配置，須要根據本身的須要在構造Jedis連接池的時候傳入連接池配置。

2. 將客戶端版本與服務端版本儘可能保持一致。
   固然若是你遇到這種問題的話，經過上面的方式仍是搞不定，說明你沒有找到正確的配置。即便有另外一份配置放在你面前，它可能也不能解決你的問題，但至少是多了一種嘗試。

   本文由博客一文多發平臺 OpenWrite 發佈！ 架構設計@工程設計@服務穩定性之路