[[405362]] 

本文轉(zhuǎn)載自微信公眾號(hào)「捉蟲大師」，作者捉蟲大師。轉(zhuǎn)載本文請(qǐng)聯(lián)系捉蟲大師公眾號(hào)。

一

在之前的文章《redis在微服務(wù)領(lǐng)域的貢獻(xiàn)》中，從一次面試經(jīng)歷中了解了redis可以在微服務(wù)中玩的這么溜，同時(shí)也從源碼角度分析了dubbo的redis注冊(cè)中心。最后得出了dubbo的redis注冊(cè)中心不能用于生產(chǎn)的結(jié)論，其中原因有如下兩點(diǎn)：

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

后來翻看了最新的代碼發(fā)現(xiàn)第一點(diǎn)已經(jīng)改善，使用scan代替了keys，可以簡單理解為keys一次查詢了redis中所有的key，scan是分頁查詢了key，阻塞時(shí)間被打散。

在服務(wù)數(shù)量不是特別多時(shí)，可以正常運(yùn)行了，那么第二點(diǎn)還是沒有解。于是在想是否可以優(yōu)化一下貢獻(xiàn)給社區(qū)呢?于是說干就干。

二

先驗(yàn)證，步驟如下：

• 使用redis注冊(cè)中心，啟動(dòng)2個(gè)provider，再啟動(dòng)1個(gè)consumer進(jìn)行消費(fèi)
• 對(duì)其中1個(gè)provider進(jìn)行kill -9
• 觀察consumer會(huì)發(fā)現(xiàn)consumer請(qǐng)求會(huì)有部分成功、部分報(bào)錯(cuò)，并且一直有報(bào)錯(cuò)，不會(huì)恢復(fù)，也就是意外宕機(jī)(未執(zhí)行注銷邏輯，kill -9可模擬)的provider不會(huì)從redis注冊(cè)中心上摘除

為什么需要啟動(dòng)2個(gè)provider?因?yàn)閐ubbo在注冊(cè)中心推送時(shí)有一個(gè)保護(hù)機(jī)制，當(dāng)推送provider列表為空時(shí)會(huì)忽略本次推送，畢竟不更新provider總比provider沒了要好吧。

分析求解

注意到redis注冊(cè)中心保存的數(shù)據(jù)是hash結(jié)構(gòu)，且key為url，value為過期時(shí)間

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" 

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

又看了一眼代碼，發(fā)現(xiàn)居然這個(gè)想法已經(jīng)實(shí)現(xiàn)了，在啟動(dòng)redis注冊(cè)中心時(shí)，起了一個(gè)線程，每隔 1/2 過期時(shí)間進(jìn)行掃描

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); 

每次掃描時(shí)

• 將注冊(cè)的服務(wù)進(jìn)行"續(xù)約"，這部分暫時(shí)不關(guān)心
• 如果是admin，進(jìn)行過期注冊(cè)信息的清理并通知

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什么時(shí)候?yàn)閠rue?

在訂閱時(shí)如果訂閱了*結(jié)尾的服務(wù)，則admin置為true，可能是dubbo控制臺(tái)

@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時(shí)可能是monitoring center?

無論如何，在生產(chǎn)中，很少有公司會(huì)用開源的monitoring center或者控制臺(tái)，大都進(jìn)行改造或者自研。

而且這種系統(tǒng)也沒法保證穩(wěn)定性，萬一掛了，豈不是很容易搞出故障。

何不在consumer側(cè)進(jìn)行服務(wù)探活呢?

剛好訂閱和變更推送時(shí)都會(huì)去redis取一次最新數(shù)據(jù)，剛好provider續(xù)期時(shí)會(huì)發(fā)布事件，如果

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

思路比較簡單，10分鐘便寫出了個(gè)demo，用上文的驗(yàn)證方法進(jìn)行驗(yàn)證，果然好使

三

好久沒有給社區(qū)貢獻(xiàn)過源碼了，于是就這樣簡單的提上去了，過了兩天收到了評(píng)論

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

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

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

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

辦法總比困難多。

又過了兩天，收到評(píng)論

please comment in English

emmm，忘了，要用英文，改完又過了兩天，收到評(píng)論

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

expireCache是用來緩存url和過期時(shí)間的map，只管往里塞，忘記清理了，會(huì)導(dǎo)致內(nèi)存泄漏。于是我又加上了清理邏輯。

這里面還有個(gè)插曲，當(dāng)天大概21-22點(diǎn)之間，我把這個(gè)內(nèi)存泄漏的bug修復(fù)了，并寫了單元測(cè)試，測(cè)試方法還是像之前那樣，通知后主線程循環(huán)檢查。本地測(cè)試沒問題后就提交到github了，當(dāng)時(shí)github上編譯失敗了，我也沒多想，畢竟dubbo這個(gè)項(xiàng)目太大了，經(jīng)常編譯失敗。

神奇的是當(dāng)天晚上回去做夢(mèng)夢(mèng)到我寫的單元測(cè)試可能少寫了個(gè)break導(dǎo)致運(yùn)行測(cè)試時(shí)，沒有及時(shí)跳出，所以本地編譯成功，github編譯失敗(超時(shí))了。

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

又過了2天，收到評(píng)論

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

emm，看到這個(gè)，我感覺他們沒有看懂代碼，于是回復(fù)了下

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

最后過了幾天終于這個(gè)PR被merge了。