作者：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)樾枰涀⒂闷胀ㄗ粉櫮Ｊ降目蛻舳嗽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)。
參考資料：
