給Dubbo貢獻源碼，做夢都在修bug
本文轉載自微信公眾號「捉蟲大師」，作者捉蟲大師。轉載本文請聯系捉蟲大師公眾號。
一
在之前的文章《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×tamp=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了。
