redis在微服務領域的貢獻

捉蟲大師 發表於 2021-10-15
Redis 微服務

本文已收錄 https://github.com/lkxiaolou/lkxiaolou 歡迎star。

前言

說到redis,可能大家的腦海中蹦出的關鍵詞是:NoSQL、KV、高效能、快取等。但今天的文章從另一個角度——微服務來展開。

這篇文章的起因也是源自一次面試經歷,在面試一位來自陌陌的候選人(就是那個交友的陌陌)時,他提到一點讓我覺得很有意思,他說redis在陌陌被使用的非常廣泛,除了常規的快取外,某些場景下也當NoSQL資料庫來使用,還用redis作為微服務的註冊中心,甚至連RPC的呼叫協議都用了redis協議。

註冊中心

最早了解到redis可以作為註冊中心是從dubbo的原始碼中看到,但一直也沒有過多的瞭解,因為從沒聽說哪家公司使用redis來做服務發現。

在dubbo中使用redis來做服務發現還是挺簡單的,引入jedis依賴,將註冊中心地址改為redis地址即可:

<dependency>
	<groupId>redis.clients</groupId>
	<artifactId>jedis</artifactId>
	<version>2.9.0</version>
</dependency>
dubbo.registry.address=redis://127.0.0.1:6379

註冊上來的資料是這樣,型別是hash

/dubbo/${service}/${category}

/dubbo/com.newboo.sample.api.DemoService/consumers
/dubbo/com.newboo.sample.api.DemoService/providers

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"

從理論上來說,註冊中心只要符合資料儲存、監聽推送變更、心跳檢測這幾個基本的功能即可。

以dubbo為例看下redis是如何利用自身特性來完成註冊中心的功能( 以dubbo 2.7.8版本為例):

  • 服務註冊

    • provider在服務註冊時,將服務提供方的url寫入/dubbo/${service}/providers下,資料型別為hash,key為提供方url,value為key的過期時間,預設為60s,可配置
    • 寫入完成後以/dubbo/${service}/providers為key呼叫publish命令釋出一個register事件
    • provider在初始化時起一個單獨的執行緒每隔1/2過期時間(預設30s)時對provider進行重新重新註冊併發布register事件
  • 服務發現

    • 獲取匹配/dubbo/${service}/*的key(此處用到了keys命令),拿到的有這幾種:/dubbo/${service}/providers/dubbo/${service}/routers/dubbo/${service}/configuators
    • /dubbo/${service}/*拿到的key進行hgetall,拿到真實的provider列表以及配置等資料,進行組裝、匹配
    • 同時對每個subscribe的服務單獨開一個執行緒,對/dubbo/${service}執行psubscribe命令阻塞等待有事件發生

image

從原始碼和測試來看,dubbo的redis註冊中心不能直接用於生產環境,原因有如下兩點:

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

雖然dubbo的redis註冊中心生產不可用,但這並不影響他可以構建一個生產可用的註冊中心,陌陌就是個很好的例子。

RPC呼叫協議

redis協議作為RPC呼叫協議也是陌陌同學告訴我的,當時我問了他兩個問題:

  • 為什麼選擇redis協議作為RPC呼叫協議
  • redis協議如何透傳類似header的隱式引數

第一個問題的答案也比較出乎意料,他說是為了跨語言呼叫,當時覺得只有http、gRPC等協議做到了跨語言,redis協議跨語言也是第一次聽說。但仔細一想,確實沒毛病,現在哪個後端語言沒有實現redis的客戶端呢?

之所以redis協議能夠做到跨語言,這也全仰仗它的設計非常簡潔,易於實現,詳細協議內容可以參考這個連結:

http://redisdoc.com/topic/protocol.html

我就舉一個例子來證明redis協議簡潔到了什麼程度,這是我很久之前就關注的一個專案

https://github.com/jdp/redisent

它是一個php實現的redis客戶端,只有一個php檔案,共196行,這196行包含了註釋,變數定義,連結建立等,真正解析協議的程式碼非常少,請求的編碼和傳送只用了17行程式碼,解析返回的程式碼只有58行!正如專案的介紹那樣:simple, no-nonsense

第二個問題回答的和我的預期一致,從redis協議的層面暫時無法支援類似header的隱式引數,但陌陌的RPC框架是自研的,所以他們在框架層解決了這個問題,序列化他們選擇了json,如果要透傳header引數,框架將引數組裝到傳輸體中去。

image

遺憾的是dubbo中的redis協議實現並不完整,無法暴露redis協議,只能呼叫,所以測試也只能測試client連線到redis伺服器進行get、set呼叫,意義不大。

總結

redis目前是個用途非常廣泛的儲存元件,雖然在微服務領域它不是主流,但這也給我們提供了一種思路,至少這條路是可以走通的。


搜尋關注微信公眾號"捉蟲大師",後端技術分享,架構設計、效能優化、原始碼閱讀、問題排查、踩坑實踐。