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

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

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

簡介

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

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

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

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

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

兩種模式

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

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

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

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

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

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

優(yōu)勢

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

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

誤區(qū)

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

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

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

功能演示

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

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

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

telnet 127.0.0.1 6379
hello 3

1、默認模式

在使用客戶端連接到redis服務(wù)后，需要先通過指令開啟tracking模式的功能，因為在客戶端連接后這個選項是默認關(guān)閉的，會無法收到失效類型的push消息：

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

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

• 開啟tracking。
• 客戶端訪問過某個key。

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

push類型的消息我們在RESP3中介紹過了，這里簡單再嘮叨兩句：

>2
$10
invalidate
*1
$4
user

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

除此之外，當一個緩存的key到達失效時間導致過期，或是因為到達最大內(nèi)存，要使用驅(qū)逐策略進行驅(qū)逐時，也會對客戶端發(fā)送PUSH的消息。下面以緩存的key過期為例：

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

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

2、廣播模式

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

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

client tracking on bcast

下面，我們通過一個例子來進行廣播模式的使用演示：

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

并且，另外一點和默認模式不同的是，廣播模式是能夠重復多次收到一個key的失效消息的，因為服務(wù)端沒有記錄，所以只要有key發(fā)生了修改，客戶端就會收到失效消息。

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

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

client tracking on bcast prefix myprefix

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

可以看到，在設(shè)置了只關(guān)注以order:作為前綴的key后，成功過濾掉了user的失效消息。從這個角度來看，也要求了我們在緩存一個類型的數(shù)據(jù)時，都以相同的單詞作為前綴，規(guī)范了我們在使用緩存中對key的命名規(guī)則。

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

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

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

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

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

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

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

client tracking on bcast redirect [client-id]

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

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

subscribe _redis_:invalidate

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

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

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

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

總結(jié)

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

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

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

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

官方文檔：

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