這篇文章的起因也是源自一次面試經(jīng)歷，在面試一位來自陌陌的候選人（就是那個交友的陌陌）時，他提到一點讓我覺得很有意思，他說redis在陌陌被使用的非常廣泛，除了常規(guī)的緩存外，某些場景下也當(dāng)NoSQL數(shù)據(jù)庫來使用，還用redis作為微服務(wù)的注冊中心，甚至連RPC的調(diào)用協(xié)議都用了redis協(xié)議。

注冊中心

最早了解到redis可以作為注冊中心是從dubbo的源碼中看到，但一直也沒有過多的了解，因為從沒聽說哪家公司使用redis來做服務(wù)發(fā)現(xiàn)。

在dubbo中使用redis來做服務(wù)發(fā)現(xiàn)還是挺簡單的，引入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

注冊上來的數(shù)據(jù)是這樣，類型是hash

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

如

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

hash數(shù)據(jù)結(jié)構(gòu)下保存的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"

從理論上來說，注冊中心只要符合數(shù)據(jù)存儲、監(jiān)聽推送變更、心跳檢測這幾個基本的功能即可。

以dubbo為例看下redis是如何利用自身特性來完成注冊中心的功能（以dubbo 2.7.8版本為例）：

服務(wù)注冊

provider在服務(wù)注冊時，將服務(wù)提供方的url寫入/dubbo/${service}/providers下，數(shù)據(jù)類型為hash，key為提供方url，value為key的過期時間，默認(rèn)為60s，可配置
寫入完成后以/dubbo/${service}/providers為key調(diào)用publish命令發(fā)布一個register事件provider在初始化時起一個單獨的線程每隔1/2過期時間（默認(rèn)30s）時對
provider進(jìn)行重新重新注冊并發(fā)布register事件

服務(wù)發(fā)現(xiàn)

獲取匹配/dubbo/${service}/*的key（此處用到了keys命令），拿到的有這幾種：/dubbo/${service}/providers、/dubbo/${service}/routers、/dubbo/${service}/configuators
對/dubbo/${service}/*拿到的key進(jìn)行hgetall，拿到真實的provider列表以及配置等數(shù)據(jù)，進(jìn)行組裝、匹配
同時對每個subscribe的服務(wù)單獨開一個線程，對/dubbo/${service}執(zhí)行psubscribe命令阻塞等待有事件發(fā)生

從源碼和測試來看，dubbo的redis注冊中心不能直接用于生產(chǎn)環(huán)境，原因有如下兩點：

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

雖然dubbo的redis注冊中心生產(chǎn)不可用，但這并不影響他可以構(gòu)建一個生產(chǎn)可用的注冊中心，陌陌就是個很好的例子。

RPC調(diào)用協(xié)議

redis協(xié)議作為RPC調(diào)用協(xié)議也是陌陌同學(xué)告訴我的，當(dāng)時我問了他兩個問題：

為什么選擇redis協(xié)議作為RPC調(diào)用協(xié)議
redis協(xié)議如何透傳類似header的隱式參數(shù)

第一個問題的答案也比較出乎意料，他說是為了跨語言調(diào)用，當(dāng)時覺得只有http、gRPC等協(xié)議做到了跨語言，redis協(xié)議跨語言也是第一次聽說。但仔細(xì)一想，確實沒毛病，現(xiàn)在哪個后端語言沒有實現(xiàn)redis的客戶端呢？

之所以redis協(xié)議能夠做到跨語言，這也全仰仗它的設(shè)計非常簡潔，易于實現(xiàn)，詳細(xì)協(xié)議內(nèi)容可以參考這個鏈接：

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

我就舉一個例子來證明redis協(xié)議簡潔到了什么程度，這是我很久之前就關(guān)注的一個項目

https://github.com/jdp/redisent

它是一個php實現(xiàn)的redis客戶端，只有一個php文件，共196行，這196行包含了注釋，變量定義，鏈接建立等，真正解析協(xié)議的代碼非常少，請求的編碼和發(fā)送只用了17行代碼，解析返回的代碼只有58行！正如項目的介紹那樣：simple, no-nonsense

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