哈嘍大家好啊，我是沒更新就是在家忙著帶娃的Hydra。

在前面介紹兩級(jí)緩存的文章中，我們總共給出了4種實(shí)現(xiàn)方案，在項(xiàng)目中整合了本地緩存Caffeine和遠(yuǎn)程緩存Redis，將應(yīng)用的性能從僅適用單獨(dú)遠(yuǎn)程緩存的基礎(chǔ)上，再次提高了一個(gè)層次。

而今天Hydra要和大家分享的技術(shù)，在思想上和上面兩級(jí)緩存有些類似，不過不需要借助其他本地緩存中間件，只使用Redis自身服務(wù)端和客戶端就可以實(shí)現(xiàn)。這就是Redis6中的客戶端緩存Client-side caching這一項(xiàng)新特性，它允許將數(shù)據(jù)緩存在應(yīng)用服務(wù)端以及遠(yuǎn)程緩存兩個(gè)位置。

簡(jiǎn)介

客戶端緩存是Redis6眾多新特性中比較實(shí)用的一項(xiàng)新功能，我們看看官方文檔，了解一下它的作用：

客戶端緩存是一種用于創(chuàng)建高性能服務(wù)的技術(shù)，它可以利用應(yīng)用服務(wù)器上的可用內(nèi)存(這些服務(wù)器通常是一些不同于數(shù)據(jù)庫(kù)服務(wù)器的節(jié)點(diǎn))，在這些應(yīng)用服務(wù)端來直接存儲(chǔ)數(shù)據(jù)庫(kù)中的一些信息。

與訪問數(shù)據(jù)庫(kù)等網(wǎng)絡(luò)服務(wù)相比，訪問本地內(nèi)存所需要的時(shí)間消耗要少得多，因此這個(gè)模式可以大大縮短應(yīng)用程序獲取數(shù)據(jù)的延遲，同時(shí)也能減輕數(shù)據(jù)庫(kù)的負(fù)載壓力。

看到這，我心想這不是和其他本地緩存Guava、Caffeine啥的一樣嗎，換湯不換藥，都是使用的應(yīng)用服務(wù)的內(nèi)存罷了。要說有什么好處，可能就是我在項(xiàng)目中能少引入一個(gè)中間件了。

不過，我這點(diǎn)淺薄的猜想，在看完客戶端緩存的具體應(yīng)用模式后，徹底被顛覆了。

兩種模式

在了解了客戶端緩存的基本功能后，我們來看看它的兩種基本應(yīng)用模式。Redis的客戶端緩存支持被稱為tracking，個(gè)人感覺翻譯為對(duì)key的追蹤就很好理解，它具有兩種模式：

• 默認(rèn)模式，服務(wù)端會(huì)記錄某個(gè)客戶端具體訪問過哪一些key，當(dāng)這些key對(duì)應(yīng)的值發(fā)生變化時(shí)，會(huì)發(fā)送失效消息給這些客戶端。這個(gè)模式會(huì)在服務(wù)端消耗一些內(nèi)存，但是發(fā)送失效消息的范圍，被限制在了客戶端存儲(chǔ)了的key的集合范圍內(nèi)。
• 廣播模式，服務(wù)端不會(huì)再記錄某個(gè)客戶端訪問了哪些key，因此這個(gè)模式不消耗服務(wù)端的內(nèi)存。取而代之的是，客戶端需要訂閱key的特定前綴，每當(dāng)符合這個(gè)前綴的key對(duì)應(yīng)的值發(fā)生改變時(shí)，客戶端都會(huì)收到通知消息。

看到這里，它和我們之前使用的兩級(jí)緩存之間差異，是不是已經(jīng)初露端倪了呢?如果還不熟悉兩級(jí)緩存的架構(gòu)，那么可以先來看看下面的這張圖：

這種架構(gòu)在理論上看起來不錯(cuò)，但是實(shí)際使用起來需要注意的點(diǎn)不少，尤其是在分布式模式下，需要保證各個(gè)主機(jī)下的一級(jí)緩存的一致性問題，回想一下我們?cè)鹊慕鉀Q方案，可以使用redis本身的發(fā)布/訂閱功能來實(shí)現(xiàn)：

而客戶端緩存的出現(xiàn)，大大簡(jiǎn)化了這一過程。我們以默認(rèn)模式為例，看一下使用了客戶端緩存后的操作過程：

相比原先的發(fā)布/訂閱模式，我們可以看到明顯的優(yōu)勢(shì)，使用客戶端緩存功能后，我們只需要單純的修改redis中的數(shù)據(jù)就可以了，手動(dòng)處理發(fā)布/訂閱消息的這一過程可以完全被省略。

優(yōu)勢(shì)

到這里，在了解了客戶端緩存的基本功能與兩種模式后，我們來對(duì)比一下，和傳統(tǒng)的只使用redis做遠(yuǎn)程緩存、以及使用整合后的兩級(jí)緩存相比較，客戶端緩存具有什么樣的優(yōu)勢(shì)。

• 當(dāng)應(yīng)用的服務(wù)端存在緩存時(shí)，會(huì)直接讀取本地緩存，能夠減少網(wǎng)絡(luò)訪問上造成的延遲，從而加快訪問速度。
• 同時(shí)也能減少訪問redis服務(wù)端的次數(shù)，降低redis的負(fù)載壓力。
• 在分布式環(huán)境下，不再需要通過發(fā)布訂閱來通知其他主機(jī)更新本地緩存，來保證數(shù)據(jù)的一致性。使用客戶端緩存后，它所具有的原生的消息通知功能，能很好地支持作廢本地緩存，保證之后訪問時(shí)能取到更新后的新數(shù)據(jù)。

誤區(qū)

在開始演示客戶端緩存的使用之前，我們先來糾正一個(gè)誤區(qū)。

雖然這個(gè)新特性被稱為客戶端緩存，但是redis本身不提供在應(yīng)用服務(wù)端緩存數(shù)據(jù)的功能，這個(gè)功能要由訪問redis的客戶端自己去實(shí)現(xiàn)。

說白了，也就是redis服務(wù)端只負(fù)責(zé)通知你，你緩存在應(yīng)用服務(wù)本地的這個(gè)key已經(jīng)作廢了，至于你本地如何緩存的這些數(shù)據(jù)，redis并不關(guān)心，也不負(fù)責(zé)。

功能演示

下面將通過一些實(shí)例來進(jìn)行演示，本文代碼的運(yùn)行前提條件是你已經(jīng)裝好了Redis6.x版本，linux環(huán)境下可以直接從官網(wǎng)下載后編譯安裝，windows環(huán)境下的安裝可以參考 手摸手教你在Windows環(huán)境下運(yùn)行Redis6.x 這篇文章。

概念上的東西我們也大體了解了，下面我們分別來看一下客戶端緩存具體實(shí)現(xiàn)的三種模式(至于為什么多了一種，后面再來細(xì)說)。在正式開始前，強(qiáng)烈建議大家先花個(gè)十幾分鐘了解一下 Redis6底層的通信協(xié)議RESP3，否則在看到具體的通信內(nèi)容時(shí)可能會(huì)存在一些疑問。

首先做一下準(zhǔn)備工作，通過telnet連接redis服務(wù)，并切換到resp3協(xié)議模式：

telnet 127.0.0.1 6379
hello 3

1、默認(rèn)模式

在使用客戶端連接到redis服務(wù)后，需要先通過指令開啟tracking模式的功能，因?yàn)樵诳蛻舳诉B接后這個(gè)選項(xiàng)是默認(rèn)關(guān)閉的，會(huì)無(wú)法收到失效類型的push消息：

#開啟
client tracking on
#關(guān)閉
client tracking off

當(dāng)開啟tracking后的默認(rèn)模式下，redis服務(wù)端會(huì)記錄每個(gè)客戶端請(qǐng)求過的key，當(dāng)key對(duì)應(yīng)的值發(fā)生變化時(shí)，會(huì)發(fā)送失效信息給客戶端。簡(jiǎn)單總結(jié)一下，也就是說這個(gè)模式能夠生效的必要前提條件有兩個(gè)：

• 開啟tracking。
• 客戶端訪問過某個(gè)key。

下面我們還是在telnet中來模擬一下這個(gè)過程，分別啟動(dòng)兩個(gè)redis客戶端，在client1中先執(zhí)行g(shù)et命令后，再在client2對(duì)相同的key執(zhí)行set操作修改它的值，之后就會(huì)在client1中收到push類型的消息。

push類型的消息我們?cè)赗ESP3中介紹過了，這里簡(jiǎn)單再嘮叨兩句：

>2
$10
invalidate
*1
$4
user

起始的第一字節(jié)>表示該消息為push類型，后面消息體中包含了兩部分內(nèi)容，第一部分表示收到的消息類型為invalidate，也就是作廢類型的信息，第二部分則是需要作廢的key是user。

除此之外，當(dāng)一個(gè)緩存的key到達(dá)失效時(shí)間導(dǎo)致過期，或是因?yàn)榈竭_(dá)最大內(nèi)存，要使用驅(qū)逐策略進(jìn)行驅(qū)逐時(shí)，也會(huì)對(duì)客戶端發(fā)送PUSH的消息。下面以緩存的key過期為例：

另外，對(duì)于單個(gè)key來說，這個(gè)tracking消息只會(huì)對(duì)客戶端發(fā)送一次，當(dāng)?shù)诙涡薷脑搆ey所對(duì)應(yīng)的值后，客戶端不會(huì)再收到tracking的消息。只有對(duì)這個(gè)key再執(zhí)行一次get命令，之后才會(huì)再次收到tracking消息。

默認(rèn)模式雖然使用起來簡(jiǎn)單，但是需要在服務(wù)端存儲(chǔ)客戶端的訪問數(shù)據(jù)，記錄哪些key被哪些客戶端訪問過。如果訪問的不是少量的熱點(diǎn)數(shù)據(jù)的話，可能會(huì)占用大量redis服務(wù)端的內(nèi)存空間。應(yīng)對(duì)這種情況，可以試一試下面要介紹的廣播模式。

2、廣播模式

在廣播模式BCAST下，redis服務(wù)端不再記錄key的訪問情況，而是無(wú)差別地向所有開啟tracking廣播的客戶端發(fā)送消息。這樣一來，好處就是不需要浪費(fèi)redis服務(wù)端的內(nèi)存進(jìn)行記錄，但是壞處就是客戶端可能會(huì)收到過多的消息，其中可能還會(huì)包含自己不需要的一些key。

在使用前，需要先通過命令開啟廣播模式：

client tracking on bcast

下面，我們通過一個(gè)例子來進(jìn)行廣播模式的使用演示：

可以看到在開啟廣播模式后，只要在client2中修改了key對(duì)應(yīng)的值，在client1中都會(huì)收到作廢消息，而不管client1之前在本地是否進(jìn)行過緩存。

并且，另外一點(diǎn)和默認(rèn)模式不同的是，廣播模式是能夠重復(fù)多次收到一個(gè)key的失效消息的，因?yàn)榉?wù)端沒有記錄，所以只要有key發(fā)生了修改，客戶端就會(huì)收到失效消息。

這時(shí)候，有的小伙伴可能就要問了，如果我不想收到這么多沒用的冗余消息，有沒有什么辦法進(jìn)行一下過濾或精簡(jiǎn)呢?

答案是可以的，在廣播模式下，客戶端可以只關(guān)注一些特定前綴的key，表示我只需要接收這些前綴的key，其他的就不要發(fā)給我了。命令格式如下：

client tracking on bcast prefix myprefix

再來看一下使用過程的示例：

可以看到，在設(shè)置了只關(guān)注以order:作為前綴的key后，成功過濾掉了user的失效消息。從這個(gè)角度來看，也要求了我們?cè)诰彺嬉粋€(gè)類型的數(shù)據(jù)時(shí)，都以相同的單詞作為前綴，規(guī)范了我們?cè)谑褂镁彺嬷袑?duì)key的命名規(guī)則。

至于在業(yè)務(wù)中具體要使用哪種模式，可能更多的需要進(jìn)行一下權(quán)衡。看一下你究竟是能忍受占用更多redis服務(wù)端的內(nèi)存，還是能夠忍受收到大量不需要的失效消息。

3、轉(zhuǎn)發(fā)模式

默認(rèn)模式和廣播模式的生效，都要在開啟RESP3協(xié)議的前提下，具體原因看過上面的例子大家應(yīng)該也都清楚了，因?yàn)橐褂胻racking的話，就必須要借助到RESP3協(xié)議中的新的push消息類型。

那么如果客戶端還是使用的舊版本RESP V2的話，也想要體驗(yàn)這一功能，應(yīng)該如何進(jìn)行改造呢?

不得不說redis6的開發(fā)者想的還是蠻全面的，為了適配RESP V2，專門設(shè)計(jì)了一種新的轉(zhuǎn)發(fā)模式，允許使用舊版本協(xié)議的客戶端通過Pub/Sub發(fā)布訂閱功能來接收key的失效信息。

從上面這張圖可以看到，轉(zhuǎn)發(fā)模式的核心就是redis服務(wù)端會(huì)將原先push類型的tracking信息，轉(zhuǎn)發(fā)到訂閱了_redis_:invalidate這一信道的被指定的客戶端上。

我們來梳理一下上面的流程，首先在client1需要使用指令開啟轉(zhuǎn)發(fā)模式：

client tracking on bcast redirect [client-id]

相對(duì)廣播模式，多了兩個(gè)參數(shù)，redirect表示為轉(zhuǎn)發(fā)模式，后面的client-id表示消息要發(fā)送給哪一個(gè)客戶端，客戶端的id可以在client2上通過client id指令獲取。

在client2中，則需要訂閱指定的信道：

subscribe _redis_:invalidate

其實(shí)說白了，轉(zhuǎn)發(fā)模式還是使用的發(fā)布訂閱功能罷了，只不過redis幫我們解放了雙手，把發(fā)送消息的工作由自己完成了。整個(gè)操作的流程如下圖所示：

可以看到，client2中收到的消息格式與之前的push類型消息不同，是一條RESP V2中多條批量回復(fù)格式的消息，表示的含義同樣是收到的key已經(jīng)作廢掉了。

需要注意的是，雖然說開啟轉(zhuǎn)發(fā)模式的指令中也帶了一個(gè)bcast，但是它和廣播模式有著非常大的區(qū)別。在轉(zhuǎn)發(fā)模式下，key的作廢消息只能被轉(zhuǎn)發(fā)到一個(gè)客戶端上，如果先后執(zhí)行兩條指定轉(zhuǎn)發(fā)指令，那么后執(zhí)行的指令會(huì)覆蓋前一指令中轉(zhuǎn)發(fā)的client-id。

看到這里是不是多少感覺這個(gè)轉(zhuǎn)發(fā)模式有點(diǎn)雞肋，畢竟實(shí)際的業(yè)務(wù)場(chǎng)景中很有可能會(huì)有多個(gè)客戶端的存在，只能轉(zhuǎn)發(fā)一個(gè)實(shí)在是有點(diǎn)說不過去了。不過，也有可能作者就是這么設(shè)計(jì)，留點(diǎn)缺陷，好讓大家更快地?fù)肀ESP3……

總結(jié)

好啦，到這里客戶端緩存的基本理論和使用就介紹的差不多了，不得不說，Redis6的這個(gè)新特性確實(shí)給了我們眼前一亮的感覺。從這個(gè)新特性也可以看出，Redis大有把緩存從服務(wù)端的局限中掙脫出來，染指向客戶端，一統(tǒng)緩存江湖的意味。

不過這個(gè)過程應(yīng)該并不簡(jiǎn)單，就像我們前面說的，畢竟只有Redis服務(wù)端還不夠，還需要優(yōu)秀的客戶端進(jìn)行支持才行。

那么下一篇文章，我們就來從實(shí)戰(zhàn)角度，看看如何改造客戶端，讓client-side caching能在項(xiàng)目中落地開花。

這次的分享就到這里，我是Hydra，下篇文章再見。

官方文檔：

https://redis.io/docs/manual/client-side-caching/。