Redis 6客戶端追蹤簡(jiǎn)介

作者:Wen Hui

轉(zhuǎn)載:中間件小哥

客戶端追蹤是Redis 6中引入的新概念。這個(gè)特性主要輔助客戶端在Redis服務(wù)端鍵值被其他客戶端更新后列粪,能及時(shí)通知客戶端將緩存過的鍵值逐出并更新耸黑。從而減少或避免數(shù)據(jù)一致性帶來的問題颜屠。目前的客戶端追蹤包含以下模式:

1)普通追蹤模式

命令:CLIENT TRACKING ON

特點(diǎn):

1.當(dāng)客戶端開啟追蹤時(shí)搀罢,服務(wù)器端保存一個(gè)無效表(Invalidation Table)來記錄所有相應(yīng)客戶端讀取過的鍵的信息艘绍。

2.當(dāng)相應(yīng)的鍵被更改時(shí),向相應(yīng)的客戶端發(fā)送緩存無效信息初狰。

普通追蹤模式優(yōu)點(diǎn):

只針對(duì)特定客戶端發(fā)送鍵無效信息莫杈。節(jié)省服務(wù)器端和客戶端CPU資源。

追蹤模式缺點(diǎn):

相對(duì)于其他模式來說耗費(fèi)更多服務(wù)器端內(nèi)存奢入,因?yàn)樾枰涀⒂闷胀ㄗ粉櫮J降目蛻舳嗽L問過的所有鍵筝闹。

例子:

如下圖所示,左上窗口代表客戶端1連接腥光,左下代表客戶端1的緩存失效消息連接关顷,右邊窗口代表客戶端2,在客戶端1查詢并模擬緩存過foo鍵的值后柴我,如果客戶端2隨后更新foo的值解寝,則客戶端1的緩存失效消息連接會(huì)接收到服務(wù)器的消息,通知foo鍵已經(jīng)被更新過了艘儒,需要客戶端重新查詢并緩存新的值聋伦。

2)廣播追蹤模式

命令:CLIENT TRACKING ON BROADCAST PREFIX <PREFIX1> <PREFIX2> …

特點(diǎn):

1. 服務(wù)器保存一個(gè)鍵前綴表(Prefix Table)來記錄客戶端需要追蹤的鍵前綴,而不是記錄所有相應(yīng)的客戶端訪問過的鍵界睁。

2. 當(dāng)滿足特定鍵前綴中的任何鍵被更新時(shí)觉增,服務(wù)器向所有訂閱特定前綴的客戶端發(fā)送緩存無效信息。

廣播追蹤模式優(yōu)點(diǎn):

服務(wù)器端只需要記住客戶端感興趣的鍵前綴信息翻斟,節(jié)省服務(wù)器端內(nèi)存逾礁。

廣播追蹤模式缺點(diǎn):

如果特定鍵前綴中的任何鍵被更新時(shí),服務(wù)器需要向所有訂閱該鍵前綴的客戶端發(fā)送緩存無效消息访惜。耗費(fèi)服務(wù)器端和客戶端CPU及網(wǎng)絡(luò)資源嘹履,并且客戶端可能收到很多沒有緩存過的鍵的無效消息。

例子:

如下圖所示债热,左邊1列代表客戶端1的客戶端連接和緩存失效消息連接砾嫉,中間一列代表客戶端2的客戶端連接和緩存失效連接,右邊一個(gè)窗口代表客戶端3.首先客戶端1和客戶端2開啟了廣播追蹤模式窒篱,客戶端1注冊(cè)了foo:和bar:兩個(gè)鍵前綴焕刮,客戶端2注冊(cè)了foo:和ttt:兩個(gè)鍵前綴∏奖客戶端1和2分別模擬查詢并緩存了foo:1和foo:2兩個(gè)鍵配并。在客戶端3更新foo:1后,因?yàn)榭蛻舳?和2都注冊(cè)了foo:前綴高镐,所以都會(huì)收到緩存失效的消息溉旋,即使客戶端2沒有緩存foo:1鍵的值。

image

3)普通追蹤模式下的OPT IN模式

命令:CLIENT TRACKING ON OPTIN

特點(diǎn):

客戶端需要顯式通過CLIENT CACHING YES命令指定下一個(gè)讀請(qǐng)求的鍵需要被追蹤(默認(rèn)情況下不追蹤)避消,其他與普通追蹤模式相同低滩。

例子:

如下圖所示召夹,左邊兩個(gè)窗口代表客戶端1的客戶端連接和緩存失效消息連接岩喷,右邊窗口代表客戶端2.客戶端1啟用客戶端追蹤OPT IN模式并模擬緩存了foo鍵恕沫,當(dāng)客戶端2更新foo鍵的值后客戶端1沒有接收到緩存失效的消息,因?yàn)镺PT IN模式是默認(rèn)不開啟的纱意。當(dāng)客戶端顯式使用CLIENT CACHING YES 并緩存foo鍵的值后婶溯,客戶端2更新foo鍵的值,這時(shí)客戶端1會(huì)接收到緩存失效消息偷霉。但CLIENT CACHING YES只對(duì)下一個(gè)讀請(qǐng)求有效迄委。

image

4)普通追蹤模式下的OPT OUT模式

命令: CLIENT TRACKING ON OPTOUT

特點(diǎn):

用戶需要顯式通過CLIENT CACHING NO指定下一個(gè)鍵不需要追蹤(默認(rèn)情況下追蹤),其他與普通追蹤模式相同类少。

例子:

如下圖所示叙身,和上一個(gè)例子類似,左邊兩個(gè)窗口代表客戶端1的客戶端連接和緩存失效消息連接硫狞,右邊窗口代表客戶端2.客戶端1啟用客戶端追蹤OPT OUT模式并模擬緩存了foo鍵信轿,與OPT IN模式相反,當(dāng)客戶端2更新foo鍵的值后客戶端1會(huì)收到緩存失效消息残吩。但當(dāng)客戶端1使用CLIENT CACHING NO并緩存rrr鍵時(shí)财忽,客戶端2更新rrr鍵,客戶端1沒有接收到緩存失效消息泣侮。因?yàn)榭蛻舳艘呀?jīng)顯示指定這個(gè)鍵rrr不需要被追蹤即彪,與OPT IN 模式相同,CLIENT CACHING NO只對(duì)下一個(gè)讀請(qǐng)求有效活尊,當(dāng)客戶端1緩存ttt并被客戶端2修改時(shí)隶校,客戶端1會(huì)恢復(fù)收到緩存失效的消息。

image

OPT IN/OUT模式優(yōu)點(diǎn):

相對(duì)于普通追蹤模式而言蛹锰,OPT IN/OUT 模式可以顯式指定那些鍵需要被追蹤哪些不需要深胳,因此相對(duì)普通追蹤模式來說更節(jié)省服務(wù)器端內(nèi)存和CPU處理時(shí)間。

OPT IN/OUT模式缺點(diǎn):

程序需要更細(xì)粒度控制對(duì)每個(gè)鍵進(jìn)行追蹤宁仔。以此帶來的實(shí)現(xiàn)復(fù)雜度稠屠。

目前Redis客戶端緩存需要注意問題

  1. 目前大部分的Redis客戶端目前沒有支持RESP3 協(xié)議,如果使用RESP2協(xié)議需要?jiǎng)?chuàng)建額外的發(fā)布訂閱客戶端連接來接收緩存無效信息翎苫。

2. Proxy端的支持权埠。

3. 雙連接模式下,客戶端更新本地緩存和接收其他客戶端更改數(shù)據(jù)導(dǎo)致的Redis緩存無效消息間存在競(jìng)態(tài)條件(race condition)煎谍。需要在客戶端程序中做仔細(xì)的處理攘蔽。

Future

根據(jù)Salvatore的社交媒體消息,未來客戶端追蹤部分代碼可能會(huì)進(jìn)行相應(yīng)改變呐粘,其中主要變動(dòng)是在特定情況下满俗,Redis服務(wù)端發(fā)送給客戶端中的緩存無效消息中直接將更改過的鍵值放入其中转捕,從而避免客戶端再向Redis服務(wù)器端讀取相應(yīng)的更新過的鍵值。從而節(jié)省服務(wù)器端和客戶端的CPU和節(jié)省系統(tǒng)網(wǎng)絡(luò)帶寬唆垃。

在接下來的文章中五芝,我們會(huì)講解這一部分的Redis源碼實(shí)現(xiàn)。

參考資料:

? https://redis.io/topics/client-side-caching

? https://github.com/antirez/redis

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 序言:七十年代末辕万,一起剝皮案震驚了整個(gè)濱河市枢步,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌渐尿,老刑警劉巖醉途,帶你破解...
    沈念sama閱讀 222,378評(píng)論 6 516
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場(chǎng)離奇詭異砖茸,居然都是意外死亡隘擎,警方通過查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 94,970評(píng)論 3 399
  • 文/潘曉璐 我一進(jìn)店門凉夯,熙熙樓的掌柜王于貴愁眉苦臉地迎上來货葬,“玉大人,你說我怎么就攤上這事恍涂”Χ瑁” “怎么了?”我有些...
    開封第一講書人閱讀 168,983評(píng)論 0 362
  • 文/不壞的土叔 我叫張陵再沧,是天一觀的道長(zhǎng)尼夺。 經(jīng)常有香客問我,道長(zhǎng)炒瘸,這世上最難降的妖魔是什么淤堵? 我笑而不...
    開封第一講書人閱讀 59,938評(píng)論 1 299
  • 正文 為了忘掉前任,我火速辦了婚禮顷扩,結(jié)果婚禮上拐邪,老公的妹妹穿的比我還像新娘。我一直安慰自己隘截,他們只是感情好扎阶,可當(dāng)我...
    茶點(diǎn)故事閱讀 68,955評(píng)論 6 398
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著婶芭,像睡著了一般东臀。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上犀农,一...
    開封第一講書人閱讀 52,549評(píng)論 1 312
  • 那天惰赋,我揣著相機(jī)與錄音,去河邊找鬼呵哨。 笑死赁濒,一個(gè)胖子當(dāng)著我的面吹牛轨奄,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播拒炎,決...
    沈念sama閱讀 41,063評(píng)論 3 422
  • 文/蒼蘭香墨 我猛地睜開眼挪拟,長(zhǎng)吁一口氣:“原來是場(chǎng)噩夢(mèng)啊……” “哼!你這毒婦竟也來了枝冀?” 一聲冷哼從身側(cè)響起舞丛,我...
    開封第一講書人閱讀 39,991評(píng)論 0 277
  • 序言:老撾萬(wàn)榮一對(duì)情侶失蹤耘子,失蹤者是張志新(化名)和其女友劉穎果漾,沒想到半個(gè)月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體谷誓,經(jīng)...
    沈念sama閱讀 46,522評(píng)論 1 319
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡绒障,尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 38,604評(píng)論 3 342
  • 正文 我和宋清朗相戀三年,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了捍歪。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片户辱。...
    茶點(diǎn)故事閱讀 40,742評(píng)論 1 353
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡,死狀恐怖糙臼,靈堂內(nèi)的尸體忽然破棺而出庐镐,到底是詐尸還是另有隱情,我是刑警寧澤变逃,帶...
    沈念sama閱讀 36,413評(píng)論 5 351
  • 正文 年R本政府宣布必逆,位于F島的核電站,受9級(jí)特大地震影響揽乱,放射性物質(zhì)發(fā)生泄漏名眉。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 42,094評(píng)論 3 335
  • 文/蒙蒙 一凰棉、第九天 我趴在偏房一處隱蔽的房頂上張望损拢。 院中可真熱鬧,春花似錦撒犀、人聲如沸福压。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,572評(píng)論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽(yáng)荆姆。三九已至,卻和暖如春嚷那,著一層夾襖步出監(jiān)牢的瞬間胞枕,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,671評(píng)論 1 274
  • 我被黑心中介騙來泰國(guó)打工魏宽, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留腐泻,地道東北人决乎。 一個(gè)月前我還...
    沈念sama閱讀 49,159評(píng)論 3 378
  • 正文 我出身青樓,卻偏偏與公主長(zhǎng)得像派桩,于是被迫代替她去往敵國(guó)和親构诚。 傳聞我的和親對(duì)象是個(gè)殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 45,747評(píng)論 2 361