[[405362]] 

本文轉載自微信公眾號「捉蟲大師」，作者捉蟲大師。轉載本文請聯系捉蟲大師公眾號。

一

在之前的文章《redis在微服務領域的貢獻》中，從一次面試經歷中了解了redis可以在微服務中玩的這么溜，同時也從源碼角度分析了dubbo的redis注冊中心。最后得出了dubbo的redis注冊中心不能用于生產的結論，其中原因有如下兩點：

• 使用了keys命令，會阻塞單線程的redis，keys執行期間，其他命令都得排隊
• 沒有心跳檢測這個功能，我測試了provider被kill -9殺死后，consumer是無法感知的。但從實現上來看是想通過存儲的過期時間來判斷服務是否可用，即需要對比url對應的value與當前的時間，如果過期應被剔除，但這部分貌似沒有實現完整

后來翻看了最新的代碼發現第一點已經改善，使用scan代替了keys，可以簡單理解為keys一次查詢了redis中所有的key，scan是分頁查詢了key，阻塞時間被打散。

在服務數量不是特別多時，可以正常運行了，那么第二點還是沒有解。于是在想是否可以優化一下貢獻給社區呢?于是說干就干。

二

先驗證，步驟如下：

• 使用redis注冊中心，啟動2個provider，再啟動1個consumer進行消費
• 對其中1個provider進行kill -9
• 觀察consumer會發現consumer請求會有部分成功、部分報錯，并且一直有報錯，不會恢復，也就是意外宕機(未執行注銷邏輯，kill -9可模擬)的provider不會從redis注冊中心上摘除

為什么需要啟動2個provider?因為dubbo在注冊中心推送時有一個保護機制，當推送provider列表為空時會忽略本次推送，畢竟不更新provider總比provider沒了要好吧。

分析求解

注意到redis注冊中心保存的數據是hash結構，且key為url，value為過期時間

127.0.0.1:6379> hgetall /dubbo/com.newboo.sample.api.DemoService/providers 
1) "dubbo://172.23.233.142:20881/com.newboo.sample.api.DemoService?anyhost=true&application=boot-samples-dubbo&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=com.newboo.sample.api.DemoService&metadata-type=remote&methods=sayHello&pid=19807&release=2.7.8&side=provider&timestamp=1621857955355" 
2) "1621858734778" 

那么就好辦了，能否定時把過期的數據刪了，并通知給consumer?

又看了一眼代碼，發現居然這個想法已經實現了，在啟動redis注冊中心時，起了一個線程，每隔 1/2 過期時間進行掃描

this.expirePeriod = url.getParameter(SESSION_TIMEOUT_KEY, DEFAULT_SESSION_TIMEOUT); 
this.expireFuture = expireExecutor.scheduleWithFixedDelay(() -> { 
    try { 
        deferExpired(); // Extend the expiration time 
    } catch (Throwable t) { // Defensive fault tolerance 
        logger.error("Unexpected exception occur at defer expire time, cause: " + t.getMessage(), t); 
    } 
}, expirePeriod / 2, expirePeriod / 2, TimeUnit.MILLISECONDS); 

每次掃描時

• 將注冊的服務進行"續約"，這部分暫時不關心
• 如果是admin，進行過期注冊信息的清理并通知

private void deferExpired() { 
    for (URL url : new HashSet<>(getRegistered())) { 
        if (url.getParameter(DYNAMIC_KEY, true)) { 
            String key = toCategoryPath(url); 
            if (redisClient.hset(key, url.toFullString(), String.valueOf(System.currentTimeMillis() + expirePeriod)) == 1) { 
                redisClient.publish(key, REGISTER); 
            } 
        } 
    } 
 
    if (admin) { 
        clean(); 
    } 
} 

這里admin什么時候為true?

在訂閱時如果訂閱了*結尾的服務，則admin置為true，可能是dubbo控制臺

@Override 
public void doSubscribe(final URL url, final NotifyListener listener) { 
    ... 
    try { 
        if (service.endsWith(ANY_VALUE)) { 
            admin = true; 
            ... 
    } catch (Throwable t) { 
        ... 
    } 
} 

而且在以前的代碼的clean方法上中有這樣一行注釋

// The monitoring center is responsible for deleting outdated dirty data 

說明admin為true時可能是monitoring center?

無論如何，在生產中，很少有公司會用開源的monitoring center或者控制臺，大都進行改造或者自研。

而且這種系統也沒法保證穩定性，萬一掛了，豈不是很容易搞出故障。

何不在consumer側進行服務探活呢?

剛好訂閱和變更推送時都會去redis取一次最新數據，剛好provider續期時會發布事件，如果

• 將這個數據緩存下來
• 每隔 1/2 過期時間去檢查數據是否已經過期
• 如果過期則去redis取一次最新的數據進行檢查(防止續期事件丟失)
• 如果真的過期了，就認為這個provider不健康

思路比較簡單，10分鐘便寫出了個demo，用上文的驗證方法進行驗證，果然好使

三

好久沒有給社區貢獻過源碼了，于是就這樣簡單的提上去了，過了兩天收到了評論

Would you please add some ut cases to verify this PR?

UT?哦，原來是unit test，忘了開源社區的玩法了，只相信測試代碼，于是我去補了單元測試。

別說測試可比代碼難多了，注冊中心的通知機制還是異步回調，更難測試。想了個巧妙的方法來測試，自定義通知回調，將回調的內容保存在一個map中，然后主線程寫個循環去檢查。

模擬服務被kill -9使用反射拿到注冊的服務，并把他移除掉，讓不再續期。

辦法總比困難多。

又過了兩天，收到評論

please comment in English

emmm，忘了，要用英文，改完又過了兩天，收到評論

Is it possible for expireCache to go leaking for it's never cleared?

expireCache是用來緩存url和過期時間的map，只管往里塞，忘記清理了，會導致內存泄漏。于是我又加上了清理邏輯。

這里面還有個插曲，當天大概21-22點之間，我把這個內存泄漏的bug修復了，并寫了單元測試，測試方法還是像之前那樣，通知后主線程循環檢查。本地測試沒問題后就提交到github了，當時github上編譯失敗了，我也沒多想，畢竟dubbo這個項目太大了，經常編譯失敗。

神奇的是當天晚上回去做夢夢到我寫的單元測試可能少寫了個break導致運行測試時，沒有及時跳出，所以本地編譯成功，github編譯失敗(超時)了。

第二天，早上來看，真的少寫了個break!!!

又過了2天，收到評論

Also, I don't see where expireCache is used inside doNotify.

emm，看到這個，我感覺他們沒有看懂代碼，于是回復了下

expireCache mark which service may be down and call doNotity to fetch latest data from redis

最后過了幾天終于這個PR被merge了。