Redis 6.0 新特性篇：Client Side Cache 是嘛玩意？
開篇寄語
不要吝嗇你的贊美，如果別人做的很好，就給他正反饋，這也是一種利他。
另外，少關注用「贊美」投票的事物，而多關注用「交易」投票的事物。
判斷一個人是否牛逼，不是看網上有多少人贊美他，而是看有多少人愿意跟他發生交易、贊賞、支付、下單。
因為贊美太廉價，而愿意與他發生交易，才是真正的信任。
為啥需要客戶端緩存
Redis 的Tracking Feature 的實現代碼在: https://github.com/antirez/redis/blob/unstable/src/tracking.c。
很多公司使用 Redis 做緩存系統，并且很好的提高了數據訪問的性能，為了進一步應對熱點數據，還是會在 Redis 的 Client 端緩存一部分熱點數據，用來應對「吃瓜事件」。
比如，「這該死的 996 福報」、「吳亦凡之大方牢房」、「時間管理大師」、「思聰舔我不得就錘我」、「吳秀波之談戀愛么，能坐牢的那種」……
除了使用 Redis 緩存避免直接訪問數據庫以外，還會加更多的cache 層，比如采用 Memcachced 作為熱點數據的本地緩存：
先去 Memcachced中查詢數據，命中直接返回。
Memcachced 未命中，則再從 Redis 查詢，命中則返回數據，并在 Memcachced 保存這個數據。
Redis 未命中，則去 MySQL中查詢，并依次設置到 Redis 和 Memcachced中。
訪問本地內存的的性能必然比通過網絡訪問 Redis 快，所以這種模式可以極大地減少獲取數據的延遲，并且可以減少 Redis 的負載，提高性能。
訪問 Redis 獲取數據，服務器響應。
查詢Redis
使用客戶端緩存，應用程序將獲取的熱門的數據存儲在應用程序中，無需再次通過網絡訪問 Redis。
應該緩存什么
- 我們不應該緩存不斷變化的鍵。
- 我們不該緩存很少請求的鍵。
- 我們希望緩存經常請求并以合理速率更改的鍵。對于沒有穩定變化速度的例子，比如不斷被INCR修改的全局計數器，就不應該緩存。
- 客戶端緩存實現原理
客戶端緩存實現原理
碼老濕， Redis 中的數據修改或者失效了，如何及時同步告知客戶端失效了呢?自己實現也太復雜了。
Redis 實現的是一個服務端協助的客戶端緩存，叫做tracking。客戶端緩存的命令是:
- CLIENT TRACKING ON|OFF [REDIRECT client-id] [PREFIX prefix] [BCAST] [OPTIN] [OPTOUT] [NOLOOP]
Redis 6.0 實現 Tracking 功能提供了兩種模式解決這個問題，分別是使用RESP3 協議版本的普通模式和廣播模式，以及使用 RESP2 協議版本的轉發模式。
普通模式
當tracking開啟時， Redis會「記住」每個客戶端請求的 key，當 key的值發現變化時會發送失效信息給客戶端 (invalidation message)。
失效信息可以通過 RESP3協議發送給請求的客戶端，或者轉發給一個不同的連接 (支持 RESP2 + Pub/Sub) 的客戶端。
Server 端將 Client 訪問的 key以及該 key 對應的客戶端 ID 列表信息存儲在全局唯一的表(TrackingTable)，當表滿了，回移除最老的記錄，同時觸發該記錄已過期的通知給客戶端。
每個 Redis 客戶端又有一個唯一的數字 ID，TrackingTable 存儲著每一個 Client ID，當連接斷開后，清除該 ID 對應的記錄。
TrackingTable 表中記錄的 Key 信息不考慮是哪個 database 的，雖然訪問的是 db1 的 key，db2 同名 key 修改時會客戶端收到過期提示，但這樣做會減少系統的復雜性，以及表的存儲數據量。
碼老濕，可以說下這個 TrackingTable 原理么?
Redis 服務端使用 TrackingTable存儲普通模式的客戶端數據，它的數據類型是基數樹 ( radix tree)。
基數樹是針對稀疏的長整型數據查找的多叉搜索樹，能快速且節省空間的完映射。
Redis 用它存儲鍵的指針和客戶端 ID 的映射關系。因為鍵對象的指針就是內存地址，也就是長整型數據。客戶端緩存的相關操作就是對該數據的增刪改查：
圖片來源-程序員厲小冰
注意
服務端對于記錄的 key 只會報告一次 invalidate 消息，也就是說，服務端在給客戶端發送過一次 invalidate 消息后，如果 key 再被修改，此時，服務端就不會再次給客戶端發送 invalidate 消息。
只有下次客戶端再次執行只讀命令被 track，才會進行下一次消息通知 。
客戶端默認不開啟 track 模式，我們需要在獲取執行指令之前執行開啟命令：
- CLIENT TRACKING ON|OFF
- +OK
- GET user:211
- $3
- 公眾號:碼哥字節
廣播模式(BCAST)
當廣播模式 (broadcasting) 開啟時，服務器不會記住給定客戶端訪問了哪些鍵，因此這種模式在服務器端根本不消耗任何內存。
在這個模式下，服務端會給客戶端廣播所有 key 的失效情況，如果 key 被頻繁修改，服務端會發送大量的失效廣播消息，這就會消耗大量的網絡帶寬資源。
所以，在實際應用中，我們設置讓客戶端注冊只跟蹤指定前綴的 key，當注冊跟蹤的 key 前綴匹配被修改，服務端就會把失效消息廣播給所有關注這個 key前綴的客戶端。
- client tracking on bcast prefix user
這種監測帶有前綴的 key 的廣播模式，和我們對 key 的命名規范非常匹配。我們在實際應用時，會給同一業務下的 key 設置相同的業務名前綴，所以，我們就可以非常方便地使用廣播模式。
圖片來源-程序員厲小冰
廣播模式與普通模式類似，Redis 使用 PrefixTable 存儲廣播模式下的客戶端數據，它存儲**前綴字符串指針和(需要通知的 key 和客戶端 ID)**的映射關系。
轉發模式
普通模式與廣播模式，需要客戶端使用 RESP 3 協議，他是 Redis 6.0 新啟用的協議。
對于使用 RESP 2 協議的客戶端來說，實現客戶端緩存則需要另一種模式：重定向模式(redirect)。
RESP 2 無法直接 PUSH 失效消息，所以 需要另一個支持 RESP 3 協議的客戶端 告訴 Server 將失效消息通過 Pus/Sub 通知給 RESP 2 客戶端。
在重定向模式下，想要獲得失效消息通知的客戶端，就需要執行訂閱命令 SUBSCRIBE，專門訂閱用于發送失效消息的頻道 _redis_:invalidate。
同時，再使用另外一個客戶端，執行 CLIENT TRACKING 命令，設置服務端將失效消息轉發給使用 RESP 2 協議的客戶端。
圖片來源-程序員厲小冰
假設客戶端 B 想要獲取失效消息，但是客戶端 B 只支持 RESP 2 協議，客戶端 A 支持 RESP 3 協議。我們可以分別在客戶端 B 和 A 上執行 SUBSCRIBE 和 CLIENT TRACKING，如下所示：
- //客戶端B執行，客戶端 B 的 ID 號是 606
- SUBSCRIBE _redis_:invalidate
- //客戶端 A 執行
- CLIENT TRACKING ON BCAST REDIRECT 606
B 客戶端就可以通過 _redis_:invalidate 頻道獲取失效消息了。
本文轉載自微信公眾號「碼哥字節」，可以通過以下二維碼關注。轉載本文請聯系碼哥字節公眾號。
