作者：Wen Hui
轉載：中間件小哥
客戶端追蹤是Redis 6中引入的新概念。這個特性主要輔助客戶端在Redis服務端鍵值被其他客戶端更新后，能及時通知客戶端將緩存過的鍵值逐出并更新。從而減少或避免數據一致性帶來的問題。目前的客戶端追蹤包含以下模式：
1）普通追蹤模式
命令：CLIENT TRACKING ON
特點：
1.當客戶端開啟追蹤時，服務器端保存一個無效表（Invalidation Table）來記錄所有相應客戶端讀取過的鍵的信息。
2.當相應的鍵被更改時，向相應的客戶端發送緩存無效信息。
普通追蹤模式優點：
只針對特定客戶端發送鍵無效信息。節省服務器端和客戶端CPU資源。
追蹤模式缺點：
相對于其他模式來說耗費更多服務器端內存，因為需要記住啟用普通追蹤模式的客戶端訪問過的所有鍵。
例子：
如下圖所示，左上窗口代表客戶端1連接，左下代表客戶端1的緩存失效消息連接，右邊窗口代表客戶端2，在客戶端1查詢并模擬緩存過foo鍵的值后，如果客戶端2隨后更新foo的值，則客戶端1的緩存失效消息連接會接收到服務器的消息，通知foo鍵已經被更新過了，需要客戶端重新查詢并緩存新的值。
2）廣播追蹤模式
命令：CLIENT TRACKING ON BROADCAST PREFIX <PREFIX1> <PREFIX2> …
特點：
1. 服務器保存一個鍵前綴表（Prefix Table）來記錄客戶端需要追蹤的鍵前綴，而不是記錄所有相應的客戶端訪問過的鍵。
2. 當滿足特定鍵前綴中的任何鍵被更新時，服務器向所有訂閱特定前綴的客戶端發送緩存無效信息。
廣播追蹤模式優點：
服務器端只需要記住客戶端感興趣的鍵前綴信息，節省服務器端內存。
廣播追蹤模式缺點：
如果特定鍵前綴中的任何鍵被更新時，服務器需要向所有訂閱該鍵前綴的客戶端發送緩存無效消息。耗費服務器端和客戶端CPU及網絡資源，并且客戶端可能收到很多沒有緩存過的鍵的無效消息。
例子：
如下圖所示，左邊1列代表客戶端1的客戶端連接和緩存失效消息連接，中間一列代表客戶端2的客戶端連接和緩存失效連接，右邊一個窗口代表客戶端3.首先客戶端1和客戶端2開啟了廣播追蹤模式，客戶端1注冊了foo：和bar：兩個鍵前綴，客戶端2注冊了foo：和ttt:兩個鍵前綴。客戶端1和2分別模擬查詢并緩存了foo：1和foo：2兩個鍵。在客戶端3更新foo：1后，因為客戶端1和2都注冊了foo：前綴，所以都會收到緩存失效的消息，即使客戶端2沒有緩存foo：1鍵的值。
3）普通追蹤模式下的OPT IN模式
命令：CLIENT TRACKING ON OPTIN
特點：
客戶端需要顯式通過CLIENT CACHING YES命令指定下一個讀請求的鍵需要被追蹤（默認情況下不追蹤），其他與普通追蹤模式相同。
例子：
如下圖所示，左邊兩個窗口代表客戶端1的客戶端連接和緩存失效消息連接，右邊窗口代表客戶端2.客戶端1啟用客戶端追蹤OPT IN模式并模擬緩存了foo鍵，當客戶端2更新foo鍵的值后客戶端1沒有接收到緩存失效的消息，因為OPT IN模式是默認不開啟的。當客戶端顯式使用CLIENT CACHING YES 并緩存foo鍵的值后，客戶端2更新foo鍵的值，這時客戶端1會接收到緩存失效消息。但CLIENT CACHING YES只對下一個讀請求有效。
4）普通追蹤模式下的OPT OUT模式
命令： CLIENT TRACKING ON OPTOUT
特點：
用戶需要顯式通過CLIENT CACHING NO指定下一個鍵不需要追蹤（默認情況下追蹤），其他與普通追蹤模式相同。
例子：
如下圖所示，和上一個例子類似，左邊兩個窗口代表客戶端1的客戶端連接和緩存失效消息連接，右邊窗口代表客戶端2.客戶端1啟用客戶端追蹤OPT OUT模式并模擬緩存了foo鍵，與OPT IN模式相反，當客戶端2更新foo鍵的值后客戶端1會收到緩存失效消息。但當客戶端1使用CLIENT CACHING NO并緩存rrr鍵時，客戶端2更新rrr鍵，客戶端1沒有接收到緩存失效消息。因為客戶端已經顯示指定這個鍵rrr不需要被追蹤，與OPT IN 模式相同，CLIENT CACHING NO只對下一個讀請求有效，當客戶端1緩存ttt并被客戶端2修改時，客戶端1會恢復收到緩存失效的消息。
OPT IN/OUT模式優點：
相對于普通追蹤模式而言，OPT IN/OUT 模式可以顯式指定那些鍵需要被追蹤哪些不需要，因此相對普通追蹤模式來說更節省服務器端內存和CPU處理時間。
OPT IN/OUT模式缺點：
程序需要更細粒度控制對每個鍵進行追蹤。以此帶來的實現復雜度。
目前Redis客戶端緩存需要注意問題
- 目前大部分的Redis客戶端目前沒有支持RESP3 協議，如果使用RESP2協議需要創建額外的發布訂閱客戶端連接來接收緩存無效信息。
2. Proxy端的支持。
3. 雙連接模式下，客戶端更新本地緩存和接收其他客戶端更改數據導致的Redis緩存無效消息間存在競態條件（race condition）。需要在客戶端程序中做仔細的處理。
Future
根據Salvatore的社交媒體消息，未來客戶端追蹤部分代碼可能會進行相應改變，其中主要變動是在特定情況下，Redis服務端發送給客戶端中的緩存無效消息中直接將更改過的鍵值放入其中，從而避免客戶端再向Redis服務器端讀取相應的更新過的鍵值。從而節省服務器端和客戶端的CPU和節省系統網絡帶寬。
在接下來的文章中，我們會講解這一部分的Redis源碼實現。
參考資料：
