詳解redis在微服務領域的貢獻
說到redis,可能大家的腦海中蹦出的關鍵詞是:NoSQL、KV、高性能、緩存等。但今天的文章從另一個角度——微服務來展開。
這篇文章的起因也是源自一次面試經歷,在面試一位來自陌陌的候選人(就是那個交友的陌陌)時,他提到一點讓我覺得很有意思,他說redis在陌陌被使用的非常廣泛,除了常規(guī)的緩存外,某些場景下也當NoSQL數據庫來使用,還用redis作為微服務的注冊中心,甚至連RPC的調用協(xié)議都用了redis協(xié)議。
注冊中心
最早了解到redis可以作為注冊中心是從dubbo的源碼中看到,但一直也沒有過多的了解,因為從沒聽說哪家公司使用redis來做服務發(fā)現。
在dubbo中使用redis來做服務發(fā)現還是挺簡單的,引入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×tamp=1621857955355"
2) "1621858734778"
從理論上來說,注冊中心只要符合數據存儲、監(jiān)聽推送變更、心跳檢測這幾個基本的功能即可。
以dubbo為例看下redis是如何利用自身特性來完成注冊中心的功能( 以dubbo 2.7.8版本為例):
服務注冊
- provider在服務注冊時,將服務提供方的url寫入
/dubbo/${service}/providers下,數據類型為hash,key為提供方url,value為key的過期時間,默認為60s,可配置 - 寫入完成后以
/dubbo/${service}/providers為key調用publish命令發(fā)布一個register事件provider在初始化時起一個單獨的線程每隔1/2過期時間(默認30s)時對 - provider進行重新重新注冊并發(fā)布register事件
服務發(fā)現
- 獲取匹配
/dubbo/${service}/*的key(此處用到了keys命令),拿到的有這幾種:/dubbo/${service}/providers、/dubbo/${service}/routers、/dubbo/${service}/configuators - 對
/dubbo/${service}/*拿到的key進行hgetall,拿到真實的provider列表以及配置等數據,進行組裝、匹配 - 同時對每個subscribe的服務單獨開一個線程,對
/dubbo/${service}執(zhí)行psubscribe命令阻塞等待有事件發(fā)生

從源碼和測試來看,dubbo的redis注冊中心不能直接用于生產環(huán)境,原因有如下兩點:
- 使用了
keys命令,會阻塞單線程的redis,keys執(zhí)行期間,其他命令都得排隊 - 沒有心跳檢測這個功能,我測試了provider被
kill -9殺死后,consumer是無法感知的。但從實現上來看是想通過存儲的過期時間來判斷服務是否可用,即需要對比url對應的value與當前的時間,如果過期應被剔除,但這部分貌似沒有實現完整
雖然dubbo的redis注冊中心生產不可用,但這并不影響他可以構建一個生產可用的注冊中心,陌陌就是個很好的例子。
RPC調用協(xié)議
redis協(xié)議作為RPC調用協(xié)議也是陌陌同學告訴我的,當時我問了他兩個問題:
- 為什么選擇redis協(xié)議作為RPC調用協(xié)議
- redis協(xié)議如何透傳類似header的
隱式參數
第一個問題的答案也比較出乎意料,他說是為了跨語言調用,當時覺得只有http、gRPC等協(xié)議做到了跨語言,redis協(xié)議跨語言也是第一次聽說。但仔細一想,確實沒毛病,現在哪個后端語言沒有實現redis的客戶端呢?
之所以redis協(xié)議能夠做到跨語言,這也全仰仗它的設計非常簡潔,易于實現,詳細協(xié)議內容可以參考這個鏈接:
http://redisdoc.com/topic/protocol.html
我就舉一個例子來證明redis協(xié)議簡潔到了什么程度,這是我很久之前就關注的一個項目
https://github.com/jdp/redisent
它是一個php實現的redis客戶端,只有一個php文件,共196行,這196行包含了注釋,變量定義,鏈接建立等,真正解析協(xié)議的代碼非常少,請求的編碼和發(fā)送只用了17行代碼,解析返回的代碼只有58行!正如項目的介紹那樣:simple, no-nonsense
第二個問題回答的和我的預期一致,從redis協(xié)議的層面暫時無法支持類似header的隱式參數,但陌陌的RPC框架是自研的,所以他們在框架層解決了這個問題,序列化他們選擇了json,如果要透傳header參數,框架將參數組裝到傳輸體中去。

遺憾的是dubbo中的redis協(xié)議實現并不完整,無法暴露redis協(xié)議,只能調用,所以測試也只能測試client連接到redis服務器進行get、set調用,意義不大。
總結
redis目前是個用途非常廣泛的存儲組件,雖然在微服務領域它不是主流,但這也給我們提供了一種思路,至少這條路是可以走通的。
到此這篇關于redis在微服務領域的貢獻的文章就介紹到這了,更多相關redis微服務內容請搜索本站以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持本站!
版權聲明:本站文章來源標注為YINGSOO的內容版權均為本站所有,歡迎引用、轉載,請保持原文完整并注明來源及原文鏈接。禁止復制或仿造本網站,禁止在非maisonbaluchon.cn所屬的服務器上建立鏡像,否則將依法追究法律責任。本站部分內容來源于網友推薦、互聯(lián)網收集整理而來,僅供學習參考,不代表本站立場,如有內容涉嫌侵權,請聯(lián)系alex-e#qq.com處理。
關注官方微信