作者: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鍵的值。
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)求有效迄委。
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ù)收到緩存失效的消息。
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客戶端緩存需要注意問題
- 目前大部分的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)。
參考資料: