dubbo服務使用redis註冊中心的系列異常解決

2022-03-01 19:01:30

前言

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註冊中心繫列異常的資料請關注it145.com其它相關文章！