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

筆者一直維護的穩定基礎服務測試環境不穩定了，這能忍！盤他，雖然不一定能完全盤的了。背景： hrexternal 基礎服務對外提供公司員工獲取的多個介面，很多介面訪問頻率比較高，加了緩存，使用的是redis，但是redis最近2個月測試環境已經出問題了，時不時的報錯，之前流程平臺也報過錯，只不過是隨 ...

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

背景：

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對象池池化技術的一個實現，相關文章如下：

https://blog.51cto.com/andrewli/2148179

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

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

maxTotal:程式允許創建資源的最大數量；預設值 -1，-1 代表無數量限制（int類型）
blockWhenExhausted：當資源耗盡時，是否阻塞等待獲取資源；預設值 true
maxWaitMillis：獲取資源時的等待時間，單位毫秒。當blockWhenExhausted 配置為 true 時，此值有效。 -1 代表無時間限制,一直阻塞直到有可用的資源。（long類型）
testOnBorrow：否在從池中取出連接前進行檢驗,如果檢驗失敗,則從池中去除連接並嘗試取出另一個；預設值 false ，當設置為true時，調用 factory.validateObject() 方法
testOnCreate 創建鏈接的時候進行鏈接有效性檢查；預設值 false，當設置為true時，調用 factory.validateObject() 方法（備註：如果 testOnBorrow 或者 testOnCreate 中有一個配置為 true 時，就調用 factory.validateObject() ）
lifo 資源的存取數據結構，預設值 true，true 資源按照棧結構存取，false 資源按照隊列結構存取
fairness 當從池中獲取資源或者將資源還回池中時是否使用 java.util.concurrent.locks.ReentrantLock.ReentrantLock 的公平鎖機制。預設值 false， true 使用公平鎖，false 不使用公平鎖，
timeBetweenEvictionRunsMillis 回收資源線程的執行周期，單位毫秒。預設值 -1 ，-1 表示不啟用線程回收資源。（long類型）
evictionPolicyClassName 資源回收策略，預設值org.apache.commons.pool2.impl.DefaultEvictionPolicy（String類型）
minEvictableIdleTimeMillis 連接在池中保持空閑而不被空閑連接回收器線程(如果有)回收的最小時間值；預設值 1800000，單位毫秒（long類型）
softMinEvictableIdleTimeMillis 軟資源最小空閑時間，預設值 -1 ，單位毫秒，（long類型）（備註，這個兩個參數，在資源回收策略中，會使用到）
maxIdle 最大空閑資源數，預設值 8 （int類型）
minIdle 最小空閑資源數，預設值 0 （int類型）
testWhileIdle 指明連接是否被空閑連接回收器(如果有)進行檢驗.如果檢測失敗,則連接將被從池中去除；預設值 false；設置為 true 時，當回收策略返回false時，則調用 factory.activateObject()和factory.validateObject()
testOnReturn 預設值 false；設置為 true 時，當將資源返還個資源池時候，驗證資源的有效性，調用 factory.validateObject()方法，如果無效，則調用 factory.destroyObject()方法
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.
不存在鏈接泄露問題。那為啥上面的錯會發生？為啥穩定運行了很長時間最近才報錯。
當然幾個可能的方向

這個Redis實例被很多服務共用，導致數據錯亂或者Redis鏈接有問題。
Jedis配置問題
版本問題。
當我設置了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點建議

不建議用Jedis預設的鏈接池配置，需要根據自己的需要在構造Jedis鏈接池的時候傳入鏈接池配置。
將客戶端版本與服務端版本儘量保持一致。
當然如果你遇到這種問題的話，通過上面的方式還是搞不定，說明你沒有找到正確的配置。即使有另一份配置放在你面前，它可能也不能解決你的問題，但至少是多了一種嘗試。

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