前言
dubbo支持zookeeper，reids，multicast等注冊中心注冊服務信息，使用redis作為注冊中心時，因為reids作為注冊中心使用并不廣泛，早期reids由于定位內網訪問，使用密碼驗證也不怎么重視，導致框架本身設計缺陷，會有很多坑，如1.沒有考慮到帶密碼驗證的redis，2.集群容錯模式判斷錯誤 3.不可以設置redisdbindex等。其中部分問題，博主已經提交給dubbo官方倉庫了，但是還沒有完全解決掉，其實這些問題無需等官方修復，對源碼稍加改造就ok了。
1.不支持帶密碼，設置indexdb的reids
2.5.6以及以前的會有這個問題，最新的版本已經解決了這個問題了，但是還是存在一個坑，就是必須得設置用戶名（大家都知道redis驗證不需要用戶名），如URL的構造方法有如下判斷
這會導致，如果只設置了密碼，沒有設置用戶名，就會拋Invalid url, password without username的異常。
解決方法：
1.打開RedisRegistry.java，設置jedispool時判斷下，如果設置密碼，使用帶密碼，indexdb入參的構造方法，具體如下：
if(StringUtils.isEmpty(url.getPassword())){
this.jedisPools.put(address, new JedisPool(config, host, port,
url.getParameter(Constants.TIMEOUT_KEY, Constants.DEFAULT_TIMEOUT),null,url.getParameter("db.index",0)));
}else {
this.jedisPools.put(address, new JedisPool(config, host, port,
url.getParameter(Constants.TIMEOUT_KEY, Constants.DEFAULT_TIMEOUT),url.getPassword(),url.getParameter("db.index",0)));
}
2.配置注冊中心的時候得把username加上，如：
二，集群容錯模式異常
這個問題，不開啟服務監控不會有問題，在開啟dubbo服務監控后，就會拋異常：Unsupported redis cluster: Failsafe. The redis cluster only supported failover or replicate，問題是由如下圖紅框內的if判斷造成的，因為監控模塊服務默認的集群容錯模式為Failsafe，而且寫死了，不可通過配置更改，如圖：
如下圖箭頭所指為添加了排除監控中心的if判斷邏輯：
三，jedis連接池連接的坑
在修改了dubbo后，由于沒有更新到修改后本地打包的dubbo依賴，一度報如下異常：
at java.lang.Thread.run(Thread.java:748) Caused by: redis.clients.jedis.exceptions.JedisException: Could not get a resource from the pool at redis.clients.util.Pool.getResource(Pool.java:51) at redis.clients.jedis.JedisPool.getResource(JedisPool.java:226) at com.alibaba.dubbo.registry.redis.RedisRegistry.doSubscribe(RedisRegistry.java:342) ... 43 more Caused by: java.util.NoSuchElementException: Unable to validate object at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:506) at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:363) at redis.clients.util.Pool.getResource(Pool.java:49) ... 45 more
Unable to validate object的問題網上有各種說法，博主也找了好久的問題，最終通過猜想+讀jedis源碼+本地debug調試才解決的問題。其實網上的說法都正確，原因是jedis內一段代碼導致的，dubbo默認設置了連接池的test.on.borrow為true，所有在拿連接前都會驗證一遍，驗證的邏輯如下：
如上圖，前面兩個判斷100%不會有問題，網上大多是因為redis服務本身出問題了，ping的時候沒有返回PONG。博主這邊是以為jedis.isConnected()報錯了，但是jedis是個坑，雖然返回了false，但是具體的異常信息并沒有拋出來，其實這個地方，具體的異常：redis.clients.jedis.exceptions.JedisDataException: NOAUTH Authentication required.。很明顯是reids密碼驗證失敗了。因為一開始修改的dubbo密碼設置沒有依賴到
四，服務超過8個應用啟動卡死
這個最終的問題還是jedis導致的，dubbo默認初始化的jedis連接池，最大鏈接數是8個，然后默認的從連接池里拿連接的超時時間為-1，又因為使用redis作為注冊中心時，通過訂閱暴露的service 的變更來做服務治理的，而jedis里的服務訂閱是阻塞占用連接的，也就是說有多少個服務，就會被占用多少個鏈接。這就導致了，當暴露的服務數量大于8個時，從連接池中獲取不到資源，又永不超時，造成應用啟動卡死的現象
解決方案：手動設置jedis的最大連接數，如：
spring.dubbo.registry.parameters.max.total = 200
文末結語
使用開源的產品，還是要多讀讀開源產品代碼，至少架構設計，模塊劃分要了解，這樣遇到啥問題，才不會手足無措，才能舉一反三。bug或異常一點都不可怕，遇到異常，解決異常就問兩個問題。1.在哪里拋出的異常（找到拋異常的代碼），2.為什么拋這個異常（找出拋異常的原因，一般有邏輯，如if判斷等，沒有的邏輯的異常一般都是系統級別的），然后通讀下異常周邊代碼，基本上問題就搞定了
以上就是dubbo服務使用redis注冊中心的系列異常解決的詳細內容，更多關于dubbo使用redis注冊中心系列異常的資料請關注服務器之家其它相關文章！
原文地址：http://www.kailing.pub/article/index/arcid/202.html
