Redis 6.0 除了多線(xiàn)程，這個(gè)功能也賊牛逼！

Redis 6.0 的新特性也是在一步步的討論和優(yōu)化中確定的。

很多的特性已經(jīng)在之前的 RC 等版本中介紹過(guò)了。

但是正式 GA 版中也有一些新的變化:

@antirez 提到只是 Redis 歷史上最大的一次版本更新，所以謹(jǐn)慎建議在應(yīng)用的產(chǎn)品中還是多多測(cè)試評(píng)估，并且承諾一旦遇到大的 bug 就會(huì)緊急發(fā)布 6.0.1 版。果不其然，一天后就發(fā)布了 6.0.1 版，修復(fù)了一個(gè) allocator 的 bug，這個(gè) bug 是為了優(yōu)化而引入的，現(xiàn)在暫時(shí)去掉了。

I just released Redis 6.0.1. Unfortunately there was a bug in Redis 6.0.0 introduced just a few days before the release, that only happens when using the non-default allocator (libc malloc in this case triggers it). Optimization reverted, 6.0.1 released. Sorry for the issue.

本文主要關(guān)注Client side caching(客戶(hù)端緩存)這一特性。

smallnest/RESP3[9] 是 Redis RESP3 協(xié)議的解析庫(kù)，你可以使用它和 Redis 底層通訊，或者包裝它實(shí)現(xiàn)新版的 Redis client 庫(kù)或者 Redis Server 端。

一年前，當(dāng) @antirez 參加完紐約 Redis 大會(huì)后，5:30 就在旅店中醒來(lái)了，面對(duì)曼哈頓街頭的美麗景色，在蕓蕓眾生中思索 Redis 的未來(lái)。，包括客戶(hù)端緩存。

其實(shí)，客戶(hù)端緩存特性是收到 Redis Conf 2018 的 Ben Malec 的影響，一下子打開(kāi)了 @antirez 思路。我們知道， 很多公司使用 Redis 做緩存系統(tǒng)，并且很好的提高了數(shù)據(jù)訪(fǎng)問(wèn)的性能，但是很多企業(yè)為了進(jìn)一步應(yīng)對(duì)熱點(diǎn)數(shù)據(jù)，還是會(huì)在 redis 的 client 端緩存一部分熱點(diǎn)數(shù)據(jù)，用來(lái)應(yīng)對(duì)吃瓜事件。比如在微博我們經(jīng)常遇到的是明星出軌、明星分分合合、突發(fā)事件等等，每年都會(huì)有幾次突發(fā)的事件，微博除了使用 Redis 做緩存避免直接訪(fǎng)問(wèn)數(shù)據(jù)庫(kù)，還會(huì)在前面加更多的 cache 層，比如 L1 cache等，采用 memcached 等產(chǎn)品作為熱數(shù)據(jù)的緩存。那么就有一個(gè)問(wèn)題，如何能夠及時(shí)的同步這些 cache 和 redis 的數(shù)據(jù)呢？Ben 提供了非常有意思的想法。

佇立在曼哈頓的街頭,@antirez 陷入了沉思，后來(lái)回到旅館他開(kāi)始實(shí)現(xiàn)初版的客戶(hù)端的緩存。當(dāng)然，最終 Redis 6.0 中實(shí)現(xiàn)和這個(gè)初版的實(shí)現(xiàn)差別很大，但是還顯然，從客戶(hù)端的演化過(guò)程中我們還是能看到@antirez 對(duì)這個(gè)特性所在的權(quán)衡(tradeoff)。關(guān)于這個(gè)歷史本文不做太多的介紹，因?yàn)槲覀兏P(guān)注于這個(gè)特性最終是什么樣子的。

Redis 實(shí)現(xiàn)的是一個(gè)服務(wù)端協(xié)助的客戶(hù)端緩存，叫做 tracking。客戶(hù)端緩存的命令是:

CLIENT TRACKING ON|OFF [REDIRECT client-id] [PREFIX prefix] [BCAST] [OPTIN] [OPTOUT] [NOLOOP]

當(dāng) tracking開(kāi)啟時(shí)， Redis 會(huì)"記住"每個(gè)客戶(hù)端請(qǐng)求的 key，當(dāng) key 的值發(fā)現(xiàn)變化時(shí)會(huì)發(fā)送失效信息給客戶(hù)端(invalidation message)。失效信息可以通過(guò) RESP3 協(xié)議發(fā)送給請(qǐng)求的客戶(hù)端，或者轉(zhuǎn)發(fā)給一個(gè)不同的連接(支持 RESP2+ Pub/Sub)。當(dāng)廣播模式(broadcasting)開(kāi)啟時(shí)，參與 tracking的客戶(hù)端會(huì)收到它通過(guò)前綴訂閱的 key 的相關(guān)的通知，即使它沒(méi)請(qǐng)求過(guò)對(duì)應(yīng)的 key。同時(shí)還提供了 OPTIN、 OPTOUT等模式。

失效消息：當(dāng)一個(gè) key 的數(shù)據(jù)有修改的時(shí)候，需要告訴客戶(hù)端它以前緩存的數(shù)據(jù)失效了，這時(shí) redis 會(huì)主動(dòng)發(fā)送一條失效消息

下面讓我們一一介紹每個(gè)選項(xiàng)。

測(cè)試環(huán)境搭建

首先讓我們介紹 RESP3 協(xié)議相關(guān)的選項(xiàng)， REDIRECT放在最后介紹。

在嘗試之前，你首先需要安裝一個(gè) redis 6.x 的版本，目前時(shí) 6.0.1。在官方網(wǎng)站上有源代碼的下載，編譯安裝也很簡(jiǎn)單：

make distclean
make
make test
sudo make install

相信很快就有編譯好的二進(jìn)制包可以下載。

啟動(dòng) server, 它會(huì)在 6379 端口啟動(dòng)一個(gè)服務(wù):

redis-server

使用 redis-cli訪(fǎng)問(wèn),默認(rèn)訪(fǎng)問(wèn)本機(jī)的 6379 實(shí)例:

redis-cli

當(dāng)然你可以通過(guò) -h查看額外的參數(shù)配置，比如使用其它端口等等，這里我們使用最簡(jiǎn)單的例子，重點(diǎn)是了解客戶(hù)端緩存的特性。

有時(shí)候?yàn)榱烁玫挠^(guān)察 redis 的返回結(jié)果，我們使用 telnet而不是 redis-cli作為 client 連接 redis，因?yàn)?redis-cli 對(duì)結(jié)果做了處理，尤其是失效消息，你可能無(wú)法觀(guān)測(cè)到。

BCAST 廣播模式 (?client tracking on)

啟動(dòng) redis server:

啟動(dòng) redis-cli:

當(dāng)然，我們使用 telnet 來(lái)測(cè)試，方便觀(guān)察 redis 的返回結(jié)果，剛才 redis-cli 用來(lái)更新 key 值，輔助測(cè)試。連接上之后發(fā)送 hello3開(kāi)啟 RESP3 協(xié)議：

telnet client
? ?~ telnet localhost 6379
Trying ::1...
Connected to localhost.
Escape character is '^]'.
hello 3
%7
$6
server
$5
redis
$7
version
$5
6.0.1
......

之后嘗試開(kāi)啟 tracking并讀取 a的值:

telnet client
client tracking on
+OK
set a 1
+OK
get a
$1
1

這個(gè)時(shí)候如果使用 redis-cli 作為另外一個(gè) client 更新 a的值，telnet 這個(gè) client 應(yīng)該能獲得通知:

redis-cli client
127.0.0.1:6379> set a 2
OK

觀(guān)察 telnet，它收到了一個(gè)失效消息：

telnet client
>2
$10
invalidate
*1
$1
a

注意它采用 RESP3 中的 PUSH 類(lèi)型( >)。

如果這個(gè)使用你再使用 redis-cli 更新 a的值，telnet 不會(huì)再收到失效消息。除非 telnet client 再 geta一次，重新 tracking a 的值。

可以隨時(shí)取消 tracking:

telnet client
client tracking off

tracking 特定前綴的 key (?client tracking on)

上面的方式會(huì) tracking 所有的 key，如果你只想跟蹤特定的 key, 目前 redis 提供了一種方式，也就是前綴匹配的方式。你可以只 tracking 特定前綴的 key。它值應(yīng)用了廣播模式。

使用 telnet client 設(shè)定前綴和開(kāi)啟 tracking：

telnet client
hello 3
.......
client tracking on prefix a bcast
+OK
client tracking on prefix user bcast
+OK

我們 tracking 兩個(gè)前綴，以 a開(kāi)頭的所有的 key 和以 user開(kāi)頭的所有的 key,所有 a開(kāi)頭的所有的 key 和以 user開(kāi)頭的所有的 key(包括 a和 user)的 key 變動(dòng)時(shí)它應(yīng)該都收到消息。

然后我們使用 redis-cli 更新三個(gè) key: abc、 user:32432723213和 feed:6532343243432:

redis-cli
127.0.0.1:6379> set abc 100
OK
127.0.0.1:6379> set user:32432723213 good
OK
127.0.0.1:6379> set feed:6532343243432 abc
OK

telnet client 收到 abc和 user:32432723213的失效消息,而不會(huì)收到 feed:6532343243432的失效消息：

telnet client
>2
$10
invalidate
*1
$3
abc
>2
$10
invalidate
*1
$16
user:32432723213

你可以通過(guò) client tracking off停止客戶(hù)端緩存。目前貌似不能只停止對(duì)單個(gè)的前綴的 tracking。即使你使用 client tracking off prefix user也是取消對(duì)所有的 key 的 tracking。

src/networking.c
......
} else if (!strcasecmp(c->argv[2]->ptr,"off")) {
 ? ?disableTracking(c);
} else {
......

選擇加入

如果使用 OPTIN,可以有選擇的開(kāi)啟 tracking。只有你發(fā)送 client caching yes之后的下一條的只讀命令的 key 才會(huì) tracking, 否則其它的只讀命令中的 key 不會(huì) tracking。

首先我們開(kāi)始 optin，讀取 a 的指，這個(gè)時(shí)候使用 redis-cli client 修改 a 的值為 1000，我們并沒(méi)有收到 a的失效消息。

telnet client
client tracking on optin
+OK
get a
$1
2

接下來(lái)我們發(fā)送 client caching yes，緊接著獲取 a 的值，這個(gè)時(shí)候如果再修改 a 的值，你就可以收到一條 a 的失效消息:

telnet client
client caching yes
+OK
get a
$4
1000
>2
$10
invalidate
*1
$1
a

必須是緊跟著 client caching yes嗎?是的，比如發(fā)送下面的命令，只會(huì) tracking b,而不是 a:

telnet client
client caching yes
+OK
get b
_
get a
$4
2000

選擇退出

如果使用 OPTOUT,你也可以有選擇的退出 tracking。只有你發(fā)送 client caching off之后的下一條的只讀命令的 key 才會(huì)停止 tracking, 否則其它的只讀命令中的 key 都會(huì)被 tracking。

可以看到它和 OPTIN正好相反，你可以根據(jù)你的場(chǎng)景來(lái)選擇。

比如下面的例子，開(kāi)啟 OPTOUT之后，對(duì)任意的 key 的變動(dòng)都收到失效消息：

telnet client
client tracking on optout
+OK
get a
$4
3000
>2
$10
invalidate
*1
$1
a

這個(gè)時(shí)候如果我們想排除 b這個(gè) key，可以只針對(duì)它進(jìn)行設(shè)置:

telnet client
client caching no
+OK
get b
$1
3

之后對(duì) b 的變動(dòng)并不會(huì)收到 b 的失效消息。

注意: OPTIN和 OPTOUT是針對(duì)的非 BCAST 場(chǎng)景，也就是只有你發(fā)送了 key 的只讀命令后，才會(huì)跟蹤相應(yīng)的 key。而廣播模式是無(wú)論你是否發(fā)送過(guò) key 的只讀命令，只要 redis 修改了 key，都會(huì)發(fā)送相應(yīng) key(或者匹配前綴的 key)的失效消息。

NOLOOP

正常設(shè)置時(shí)，失效消息是發(fā)給所有參與的 client，但是如果設(shè)置了 NOLOOP,則不會(huì)發(fā)送給更新這個(gè) key 的 client。

telnet client
client tracking on bcast noloop
+OK
set a 1
+OK
client tracking off
+OK
client tracking on bcast
+OK
set a 1
+OK
>2
$10
invalidate
*1
$1
a

注意，取消 tracking 只需調(diào)用 client tracking off即可。

REDIRECT

最后，讓我們看一下轉(zhuǎn)發(fā)消息的處理。這是為了兼容 RESP2 協(xié)議一個(gè)處理方式，將失效消息轉(zhuǎn)發(fā)給另外一個(gè) client。

首先我們查看 redis-cli 的 client id:

redis-cli
127.0.0.1:6379> client list
id=4 addr=127.0.0.1:61017 fd=8 name= age=33103 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=26 qbuf-free=32742 obl=0 oll=0 omem=0 events=r cmd=client user=default

使用 telnet 連接 redis,查看 client id:

telnet client
client id
:12

telnet 客戶(hù)端開(kāi)啟訂閱失效消息：

telnet client
SUBSCRIBE __redis__:invalidate
*3
$9
subscribe
$20
__redis__:invalidate
:1

然后我們就可以將 redis-cli 的失效消息轉(zhuǎn)發(fā)給 telnet client:

redis-cli
client tracking on bcast redirect 12
127.0.0.1:6379> set a 1000
OK

可以看到 telnet 客戶(hù)端收到了失效消息：

telnet client
*3
$7
message
$20
__redis__:invalidate
*1
$1
a

如果你要轉(zhuǎn)發(fā)的目的 client 開(kāi)啟了 RESP3 協(xié)議，你就不需要 RESP3 Pub/Sub 了，因?yàn)?RESP3 原生支持 Push 消息。