本文已收錄 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×tamp=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事件
- provider在服務注冊時，將服務提供方的url寫入
-
服務發現
- 獲取匹配
/dubbo/${service}/*的key（此處用到了keys命令），拿到的有這幾種：/dubbo/${service}/providers、/dubbo/${service}/routers、/dubbo/${service}/configuators - 對
/dubbo/${service}/*拿到的key進行hgetall，拿到真實的provider串列以及配置等資料，進行組裝、匹配 - 同時對每個subscribe的服務單獨開一個執行緒，對
/dubbo/${service}執行psubscribe命令阻塞等待有事件發生
- 獲取匹配
從原始碼和測驗來看，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引數，框架將引陣列裝到傳輸體中去，
遺憾的是dubbo中的redis協議實作并不完整，無法暴露redis協議，只能呼叫，所以測驗也只能測驗client連接到redis服務器進行get、set呼叫，意義不大，
總結
redis目前是個用途非常廣泛的存盤組件，雖然在微服務領域它不是主流，但這也給我們提供了一種思路，至少這條路是可以走通的，
搜索關注微信公眾號"捉蟲大師"，后端技術分享，架構設計、性能優化、原始碼閱讀、問題排查、踩坑實踐，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/317452.html
標籤：Java