前言

dubbo支持zookeeper，reids，multicast等注冊中心注冊服務(wù)信息，使用redis作為注冊中心時，因為reids作為注冊中心使用并不廣泛，早期reids由于定位內(nèi)網(wǎng)訪問，使用密碼驗證也不怎么重視，導(dǎo)致框架本身設(shè)計缺陷，會有很多坑，如1.沒有考慮到帶密碼驗證的redis，2.集群容錯模式判斷錯誤 3.不可以設(shè)置redisdbindex等。其中部分問題，博主已經(jīng)提交給dubbo官方倉庫了，但是還沒有完全解決掉，其實這些問題無需等官方修復(fù)，對源碼稍加改造就ok了。

1.不支持帶密碼，設(shè)置indexdb的reids

2.5.6以及以前的會有這個問題，最新的版本已經(jīng)解決了這個問題了，但是還是存在一個坑，就是必須得設(shè)置用戶名（大家都知道redis驗證不需要用戶名），如URL的構(gòu)造方法有如下判斷

這會導(dǎo)致，如果只設(shè)置了密碼，沒有設(shè)置用戶名，就會拋Invalid url, password without username的異常。

解決方法：

1.打開RedisRegistry.java，設(shè)置jedispool時判斷下，如果設(shè)置密碼，使用帶密碼，indexdb入?yún)⒌臉?gòu)造方法，具體如下：

            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加上，如：

二，集群容錯模式異常

這個問題，不開啟服務(wù)監(jiān)控不會有問題，在開啟dubbo服務(wù)監(jiān)控后，就會拋異常：Unsupported redis cluster: Failsafe. The redis cluster only supported failover or replicate，問題是由如下圖紅框內(nèi)的if判斷造成的，因為監(jiān)控模塊服務(wù)默認的集群容錯模式為Failsafe，而且寫死了，不可通過配置更改，如圖：

如下圖箭頭所指為添加了排除監(jiān)控中心的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的問題網(wǎng)上有各種說法，博主也找了好久的問題，最終通過猜想+讀jedis源碼+本地debug調(diào)試才解決的問題。其實網(wǎng)上的說法都正確，原因是jedis內(nèi)一段代碼導(dǎo)致的，dubbo默認設(shè)置了連接池的test.on.borrow為true，所有在拿連接前都會驗證一遍，驗證的邏輯如下：

如上圖，前面兩個判斷100%不會有問題，網(wǎng)上大多是因為redis服務(wù)本身出問題了，ping的時候沒有返回PONG。博主這邊是以為jedis.isConnected()報錯了，但是jedis是個坑，雖然返回了false，但是具體的異常信息并沒有拋出來，其實這個地方，具體的異常：redis.clients.jedis.exceptions.JedisDataException: NOAUTH Authentication required.。很明顯是reids密碼驗證失敗了。因為一開始修改的dubbo密碼設(shè)置沒有依賴到

四，服務(wù)超過8個應(yīng)用啟動卡死

這個最終的問題還是jedis導(dǎo)致的，dubbo默認初始化的jedis連接池，最大鏈接數(shù)是8個，然后默認的從連接池里拿連接的超時時間為-1，又因為使用redis作為注冊中心時，通過訂閱暴露的service 的變更來做服務(wù)治理的，而jedis里的服務(wù)訂閱是阻塞占用連接的，也就是說有多少個服務(wù)，就會被占用多少個鏈接。這就導(dǎo)致了，當(dāng)暴露的服務(wù)數(shù)量大于8個時，從連接池中獲取不到資源，又永不超時，造成應(yīng)用啟動卡死的現(xiàn)象

解決方案：手動設(shè)置jedis的最大連接數(shù)，如：

spring.dubbo.registry.parameters.max.total = 200

文末結(jié)語

使用開源的產(chǎn)品，還是要多讀讀開源產(chǎn)品代碼，至少架構(gòu)設(shè)計，模塊劃分要了解，這樣遇到啥問題，才不會手足無措，才能舉一反三。bug或異常一點都不可怕，遇到異常，解決異常就問兩個問題。1.在哪里拋出的異常（找到拋異常的代碼），2.為什么拋這個異常（找出拋異常的原因，一般有邏輯，如if判斷等，沒有的邏輯的異常一般都是系統(tǒng)級別的），然后通讀下異常周邊代碼，基本上問題就搞定了

以上就是dubbo服務(wù)使用redis注冊中心的系列異常解決的詳細內(nèi)容，更多關(guān)于dubbo使用redis注冊中心系列異常的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論