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

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

當然本文的分析內容也包括這個，其中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 發布！
架構設計@工程設計@服務穩定性之路

標籤：其他

上一篇：MySQL學習——管理用戶權限

下一篇：MySQL問題記錄——2003-Can't connect to MySQL server on 'localhost'(10038)