快捷導(dǎo)航

詳解redis在微服務(wù)領(lǐng)域的貢獻(xiàn)

更新時(shí)間：2021年10月15日 16:15:50 作者：捉蟲(chóng)大師

本文以dubbo為例看下redis是如何利用自身特性來(lái)完成注冊(cè)中心的功能，對(duì)redis微服務(wù)相關(guān)知識(shí)感興趣的朋友一起看看吧

前言

說(shuō)到redis，可能大家的腦海中蹦出的關(guān)鍵詞是：NoSQL、KV、高性能、緩存等。但今天的文章從另一個(gè)角度——微服務(wù)來(lái)展開(kāi)。

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

注冊(cè)中心

最早了解到redis可以作為注冊(cè)中心是從dubbo的源碼中看到，但一直也沒(méi)有過(guò)多的了解，因?yàn)閺臎](méi)聽(tīng)說(shuō)哪家公司使用redis來(lái)做服務(wù)發(fā)現(xiàn)。

在dubbo中使用redis來(lái)做服務(wù)發(fā)現(xiàn)還是挺簡(jiǎn)單的，引入jedis依賴，將注冊(cè)中心地址改為redis地址即可：

<dependency>
	<groupId>redis.clients</groupId>
	<artifactId>jedis</artifactId>
	<version>2.9.0</version>
</dependency>

dubbo.registry.address=redis://127.0.0.1:6379

注冊(cè)上來(lái)的數(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是注冊(cè)上來(lái)的url，value是過(guò)期時(shí)間

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"

從理論上來(lái)說(shuō)，注冊(cè)中心只要符合數(shù)據(jù)存儲(chǔ)、監(jiān)聽(tīng)推送變更、心跳檢測(cè)這幾個(gè)基本的功能即可。

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

服務(wù)注冊(cè)

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

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

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

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

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

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

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

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

為什么選擇redis協(xié)議作為RPC調(diào)用協(xié)議
redis協(xié)議如何透?jìng)黝愃苃eader的隱式參數(shù)

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

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

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

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

https://github.com/jdp/redisent

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

第二個(gè)問(wèn)題回答的和我的預(yù)期一致，從redis協(xié)議的層面暫時(shí)無(wú)法支持類似header的隱式參數(shù)，但陌陌的RPC框架是自研的，所以他們?cè)诳蚣軐咏鉀Q了這個(gè)問(wèn)題，序列化他們選擇了json，如果要透?jìng)鱤eader參數(shù)，框架將參數(shù)組裝到傳輸體中去。