av激情亚洲男人的天堂国语,日韩欧美精品一中文字幕,无码av一区二区三区无码,国产又色又爽又刺激的a片,国产又色又爽又刺激的a片

給Dubbo貢獻源碼，做夢都在修bug

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

一

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

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

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

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

二

先驗證，步驟如下：

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

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

分析求解

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

 
 
 
 
      
  
  
  
  1. 127.0.0.1:6379> hgetall /dubbo/com.newboo.sample.api.DemoService/providers 
    2.   
  
  
  
  2. 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×tamp=1621857955355" 
    3.   
  
  
  
  3. 2) "1621858734778" 
    4.

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

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

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

每次掃描時

  • 將注冊的服務(wù)進行"續(xù)約"，這部分暫時不關(guān)心
  • 如果是admin，進行過期注冊信息的清理并通知
 
 
 
 
      
  
  
  
  1. private void deferExpired() { 
    2.   
  
  
  
  2.     for (URL url : new HashSet<>(getRegistered())) { 
    3.   
  
  
  
  3.         if (url.getParameter(DYNAMIC_KEY, true)) { 
    4.   
  
  
  
  4.             String key = toCategoryPath(url); 
    5.   
  
  
  
  5.             if (redisClient.hset(key, url.toFullString(), String.valueOf(System.currentTimeMillis() + expirePeriod)) == 1) { 
    6.   
  
  
  
  6.                 redisClient.publish(key, REGISTER); 
    7.   
  
  
  
  7.             } 
    8.   
  
  
  
  8.         } 
    9.   
  
  
  
  9.     } 
    10.   
  
  
  
  10.  
    11.   
  
  
  
  11.     if (admin) { 
    12.   
  
  
  
  12.         clean(); 
    13.   
  
  
  
  13.     } 
    14.   
  
  
  
  14. } 
    15.

這里admin什么時候為true?

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

 
 
 
 
      
  
  
  
  1. @Override 
    2.   
  
  
  
  2. public void doSubscribe(final URL url, final NotifyListener listener) { 
    3.   
  
  
  
  3.     ... 
    4.   
  
  
  
  4.     try { 
    5.   
  
  
  
  5.         if (service.endsWith(ANY_VALUE)) { 
    6.   
  
  
  
  6.             admin = true; 
    7.   
  
  
  
  7.             ... 
    8.   
  
  
  
  8.     } catch (Throwable t) { 
    9.   
  
  
  
  9.         ... 
    10.   
  
  
  
  10.     } 
    11.   
  
  
  
  11. } 
    12.

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

 
 
 
 
      
  
  
  
  1. // The monitoring center is responsible for deleting outdated dirty data 
    2.

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

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

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

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

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

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

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

三

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

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

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

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

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

辦法總比困難多。

又過了兩天，收到評論

please comment in English

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

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

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

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

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

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

又過了2天，收到評論

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

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

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

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


文章標題：給Dubbo貢獻源碼，做夢都在修bug
網(wǎng)站網(wǎng)址：http://uogjgqi.cn/article/dpdcsic.html
掃二維碼與項目經(jīng)理溝通

我們在微信上24小時期待你的聲音

解答本文疑問/技術(shù)咨詢/運營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流