Redis 6.0更新放大招：客戶端緩存怎麼用好

近日 Redis 6.0.0 GA 版本發佈，這是 Redis 歷史上最大的一次版本更新，包括了客戶端緩存 (Client side caching)、ACL、Threaded I/O 和 Redis Cluster Proxy 等諸多更新。

咱們今天就依次聊一下客戶端緩存的必要性、具體使用、原理分析和實現。

爲何須要客戶端緩存

咱們都知道，使用 Redis 進行數據的緩存主要目的是減小對 MySQL 等數據庫的訪問，提供更快的訪問速度，畢竟 《Redis in Action》中提到的， Redis 的性能大體是普通關係型數據庫的 10 ~ 100 倍。

因此，以下圖所示，Redis 用來存儲熱點數據，Redis 未命中，再去訪問數據庫，這樣能夠應付大多數狀況下的性能要求。

可是，Redis 也有其性能上限，而且訪問 Redis 必然有必定的網絡 I/O 以及序列化反序列化損耗。因此，每每會引入進程緩存，將最熱的數據存儲在本地，進一步加快訪問速度。

如上圖所示(示意圖，細節沒必要過分在乎，下同)，Guava Cache 等進程緩存做爲一級緩存，Redis 做爲二級緩存：

• 先去 Guava Cache 中查詢數據，若是命中則直接返回。

• Guava Cache 中未命中，則再去 Redis 中查詢，若是命中則返回數據，並在 Guava Cache 中設置此數據。

• Redis 也未命中的話，只有去 MySQL 中查詢，而後依次將數據設置到 Redis 和 Guava Cache 中。

只使用 Redis 分佈式緩存時，遇到數據更新時，應用程序更新完 MySQL 中的數據，能夠直接將 Redis 中對應緩存失效掉，保持數據的一致性。

而進程內緩存的數據一致性比分佈式的緩存面臨更大的挑戰。數據更新的時候，如何通知其餘進程也更新本身的緩存呢?

若是按照分佈式緩存的思路，咱們能夠設置極短的緩存失效時間，這樣沒必要實現複雜的通知機制。

可是不一樣進程內的數據依然會面臨不一致的問題，而且不一樣進程緩存失效時間不統一，同一個請求到了不一樣的進程，可能出現反覆幻讀的狀況。

Ben 在 RedisConf18 給出了一個方案(視頻和 PPT 連接在文末)，經過 Redis 的 Pub/Sub，能夠通知其餘進程緩存對此緩存進行刪除。若是 Redis 掛了或者訂閱機制不靠譜，依靠超時設定，依然能夠作兜底處理。

Antirez(Redis 的做者)也正是聽取 Ben 這個方案後，才決定在 Redis Server 支持客戶端緩存的，由於在有服務端參與的狀況下能夠更好的處理上述這些問題。

功能介紹和演示

下面使用 Docker 安裝 Redis 6.0.1，而後使用 telnet 來簡單演示一下 Redis 6.0 的客戶端緩存功能。全部相關的功能以下圖所示，分別是使用RESP3 協議版本的普通模式和廣播模式，以及使用 RESP2 協議版本的轉發模式。咱們先來看普通模式。

普通模式

先使用 redis-cli 設置緩存值 test=111，使用 telnet 鏈接上 Redis，而後發送 hello 3 開啓 RESP3 協議。

1.  `[root@VM_0_3_centos ~]# telnet 127.0.0.1 6379`

2.  `Trying  127.0.0.1...`

3.  `Connected to 127.0.0.1.`

4.  `Escape character is  '^]'.`

5.  `hello 3`

6.  `// telnet 輸出結果格式化標準化後以下，不然換行太多而且是 RESP3 格式，不須要了解格式。`

7.  `> HELLO 3`

8.  `1# "server" => "redis"`

9.  `2# "version" => "6.0.1"`

10.  `3# "proto" => (integer) 3`

11.  `4# "id" => (integer) 10`

12.  `5# "mode" => "standalone"`

13.  `6# "role" => "master"`

14.  `7# "modules" => (empty array)`
複製代碼

這裏須要注意，Redis 服務端只會 track 客戶端在一個鏈接生命週期內的獲取的只讀命令的 key值。Redis 客戶端默認不開啓 track 模式，須要使用命令開啓，而後必需要先獲取一次 test 的值，這樣 Redis 服務器纔會記錄它。

1.  `client tracking on`

2.  `+OK`

3.  `get test`

4.  `$3`

5.  `111`
複製代碼

**當鍵被修改，或者由於失效時間(expire time)和內存上限 maxmemory 策略被驅除時，Redis 服務端會通知這些客戶端。**咱們這裏簡單地更新 test 的值，telnet 則會收到以下通知：

1.  `>2  // RESP3 中的 PUSH 類型，標誌爲 > 符號`

2.  `$10`

3.  `invalidate`

4.  `*1`

5.  `$4`

6.  `test`
複製代碼

若是你再一次更新 test 值，此次 telnet 就不會再收到失效(invalidate)消息。除非 telnet 再進行一次 get 操做，從新 tracking 對應的鍵值。

也就是說 Redis 服務端記錄的客戶端 track 信息只生效一次，發送過失效消息後就會刪除，只有下次客戶端再次執行只讀命令被 track，纔會進行下一次消息通知 。

取消 tracking 的命令以下所示：

1.  `client tracking off`

2.  `+OK`
複製代碼

廣播模式

Redis 還提供了一種廣播模式(BCAST)，它是另一種客戶端緩存的實現方式。這種方式下Redis 服務端再也不消耗過多內存存儲信息，而是發送更多的失效消息給客戶端。

這是服務端存儲過多數據，消耗內存和客戶端收到過多消息，消耗網絡帶寬之間的權衡(tradeoff)。

1.  `// 已經 hello 3 開啓 RESP3 協議，否則沒法收到失效消息，下同`

2.  `client tracking on bcast`

3.  `+OK`

4.  `// 此時設置 key 爲 a 的鍵值，收到以下消息。`

5.  `>2`

6.  `$10`

7.  `invalidate`

8.  `*1`

9.  `$1`

10.  `a`
複製代碼

若是你不想全部的鍵值的失效消息都收到，則能夠限制 key 的前綴，以下命令則表示只關注前綴爲 test 的鍵值的消息。通常來講，業務的緩存 key 都是根據業務擁有統一的前綴，因此這一特性十分方便。

1.  `client tracking on bcast prefix test`
複製代碼

與普通模式必須獲取一次鍵的規則不一樣，廣播模式下，只要鍵被修改或刪除，符合規則的客戶端都會收到失效消息，並且是能夠屢次獲取的。

與普通模式相比，雖然少存儲了一些數據，可是因爲須要對前綴規則進行匹配，會消耗必定的 CPU 資源，因此注意別使用過長的前綴。

轉發模式

上述操做時客戶端都須要先開啓 RESP3，Redis 爲了兼容 RESP2 協議提供了轉發(Redirect)模式，再也不使用 RESP3 原生支持 PUSH 消息，而是將消息經過 Pub/Sub 通知給另一個客戶端，具體流程以下圖所示：

這裏須要兩個 telnet，其中一個 telnet 須要訂閱 redis:invalidate 信道。而後另外一個 telnet 開啓 Redirect 模式，並制定將失效消息經過訂閱信道發送給第一個 telnet。

1.  `# telent B`

2.  `client id`

3.  `:368`

4.  `subscribe _redis_:invalidate`

6.  `# telnet A，開啓 track 並指定轉發給 B`

7.  `client tracking on bcast redirect 368`

9.  `# telent B 此時有鍵值被修改，收到 __redis__:invalidate 信道的消息`

10.  `message`

11.  `$20`

12.  `__redis__:invalidate`

13.  `*1`

14.  `$1`

15.  `a`

複製代碼

你會發現，轉發模式和文章開始提到的多級緩存中的更新機制很相似了，只不過那個方案中是業務系統修改完 key 後發送消息通知，而這裏是 Redis 服務端代替業務系統發送消息通知。

OPTIN和OPTOUT選項

使用 OPTIN 能夠選擇性的開啓 tracking。只有你發送 client caching yes (Redis 文檔中是 CACHING 命令，可是實驗時發現無效)以後的下一條的只讀命令的 key 纔會 tracking，不然其餘的只讀命令的 key 不會被 tracking。

1.  `client tracking on optin`

2.  `client caching yes`

3.  `get a`

4.  `get b`

5.  `// 此時修改 a 和 b 的值，發現只收到 a 的失效消息`

6.  `>2`

7.  `$10`

8.  `invalidate`

9.  `*1`

10.  `$1`

11.  `a`
複製代碼

而 OPTOUT 參數與之相反，你能夠有選擇的退出 tracking。發送 client caching off 以後的下一條只讀命令的 key 不會被 tracking，其餘只讀命令都會被 tracking。

OPTIN 和 OPTOUT 是針對非 BCAST 模式，也就是隻有發送了某個 key 的只讀命令後，纔會追蹤相應的 key。而 BCAST 模式是不管你是否發送某個 key 的只讀命令，只有 Redis 修改了 key，都會發送相應的 key 的失效消息(前綴匹配的)。

NOLOOP選項

默認狀況下，失效消息會發送給全部須要的 Redis 客戶端，可是有些狀況下觸發失效消息也就是更新 key 的客戶端不須要收到該消息。

設置 NOLOOP，能夠避免這種狀況，更新 Key 的客戶端將再也不收到消息，該選項在普通模式和廣播模式下都適用。

trackingtablemax_keys

最大 tracking 上限 trackingtablemax_keys。

由上文能夠知道，普通模式下須要存儲大量的被 tracking 的 key 和客戶端信息(具體存儲的數據下文中會講解)，因此當 10k 客戶端使用該模式處理百萬個鍵時，會消耗大量的內存空間，因此 Redis 引入了 trackingtablemax_keys 配置，默認爲無，不限制。

當有一個新的鍵被 tracking 時，若是當前 tracking 的 key 的數量大於 trackingtablemax_keys，則會隨機刪除以前 tracking 的 key，而且向對應的客戶端發送失效消息。

原理和源碼實現普通模式原理

咱們也先講解普通模式的原理，Redis 服務端使用 TrackingTable 存儲普通模式的客戶端數據，它的數據類型是基數樹(radix tree)。

基數樹是針對稀疏的長整型數據查找的多叉搜索樹，能快速且節省空間的完映射，通常用於解決 Hash衝突和 Hash表大小的設計問題，Linux 的內存管理就使用了它。

Redis 用它存儲鍵的指針和客戶端 ID 的映射關係。由於鍵對象的指針就是內存地址，也就是長整型數據。客戶端緩存的相關操做就是對該數據的增刪改查：

• 當開啓 track 功能的客戶端獲取某一個鍵值時，Redis 會調用 enableTracking 方法使用基數樹記錄下該 key 和 clientId 的映射關係。

• 當某一個 key 被修改或刪除時，Redis 會調用 trackingInvalidateKey 方法根據 key 從 TrackingTable 中查找全部對應的客戶端ID，而後調用 sendTrackingMessage 方法發送失效消息給這些客戶端(會檢查 CLIENT_TRACKING 相關標誌位是否開啓和是否開啓了 NOLOOP)。

• 發送完失效消息後，根據鍵的指針值將映射關係從 TrackingTable中刪除。

• 客戶端關閉 track 功能後，由於刪除須要進行大量操做，因此 Redis 使用懶刪除方式，只是將該客戶端的 CLIENT_TRACKING 相關標誌位刪除掉。

廣播模式原理

廣播模式與普通模式相似，Redis 一樣使用 PrefixTable 存儲廣播模式下的客戶端數據，它存儲前綴字符串指針和(須要通知的key和客戶端ID)的映射關係。它和廣播模式最大的區別就是真正發送失效消息的時機不一樣：

• 當客戶端開啓廣播模式時，會在 PrefixTable的前綴對應的客戶端列表中加入該客戶端ID。

• 當某一個 key 被修改或刪除時，Redis 會調用 trackingInvalidateKey 方法， trackingInvalidateKey 方法中若是發現 PrefixTable 不爲空，則調用 trackingRememberKeyToBroadcast 依次遍歷全部前綴，若是key 符合前綴規則，則記錄到 PrefixTable 對應的位置。

• 在 Redis 的事件處理周期函數 beforeSleep 函數裏會調用 trackingBroadcastInvalidationMessages 函數來真正發送消息。

處理最大tracking上限

Redis 會在每次執行過命令後(processCommand方法)調用 trackingLimitUsedSlots 來判斷是否須要進行清理：

• 判斷 TrackingTable 中鍵的數量是否大於 trackingtablemax_keys；

• 在必定時間段內(不能太長，阻塞主流程)，隨機從 TrackingTable 中選出一個鍵刪除，直到數量小於或者時間用完爲止。

具體源碼

關於源碼，在 tracking.c 文件下，咱們這裏只看一下最爲關鍵的 trackingInvalidateKey 函數和 sendTrackingMessage 函數，理解了這兩個函數，廣播模式和處理最大 tracking 上限等相關函數都與之相似。

1.  `void trackingInvalidateKey(client *c, robj *keyobj)  {`

2.  `if  (TrackingTable  == NULL)  return;`

3.  `sds sdskey = keyobj->ptr;`

4.  `// 省略，若是廣播模式的記錄基數樹不爲空，則先處理廣播模式`

5.  `// 1 根據鍵的指針去 TrackingTable 查找`

6.  `rax *ids = raxFind(TrackingTable,(unsigned  char*)sdskey,sdslen(sdskey));`

7.  `if  (ids == raxNotFound)  return;`

8.  `// 2 使用迭代器遍歷`

9.  `raxIterator ri;raxStart(&ri,ids);raxSeek(&ri,"^",NULL,0);`

10.  `while(raxNext(&ri))  {`

11.  `// 3 根據 clientId 查找 client 實例`

12.  `client *target = lookupClientByID(id);`

13.  `// 4 若是未開啓 track 或者是廣播模式則跳過。`

14.  `if  (target == NULL ||`

15.  `!(target->flags & CLIENT_TRACKING)||`

16.  `target->flags & CLIENT_TRACKING_BCAST)`

17.  `{  continue;  }`

18.  `// 5 若是開啓了 NOLOOP 而且是致使key發生變化的client則跳過。`

19.  `if  (target->flags & CLIENT_TRACKING_NOLOOP &&`

20.  `target == c)`

21.  `{  continue;  }`

22.  `// 6 發送失效消息`

23.  `sendTrackingMessage(target,sdskey,sdslen(sdskey),0);`

24.  `}`

25.  `// 7 減小數據統計，根據sdskey刪除對應的記錄`

26.  `TrackingTableTotalItems  -= raxSize(ids);`

27.  `raxFree(ids);`

28.  `raxRemove(TrackingTable,(unsigned  char*)sdskey,sdslen(sdskey),NULL);`

29.  `}`
複製代碼

源碼如上所示，trackingInvalidateKey 方法主要作了 7 件事情：

• 根據鍵的指針去 TrackingTable 查找客戶端ID列表；

• 使用迭代器遍歷列表；

• 根據 clientId 查找 client 實例；

• 若是 client 實例未開啓 track 或者是廣播模式則跳過；

• 若是 client 實例開啓了 NOLOOP 而且是致使key發生變化的client則跳過；

• 調用 sendTrackingMessage 方法發送失效消息；

• 減小數據統計，根據sdskey刪除對應的記錄

下面來看真正發送消息的 sendTrackingMessage 函數，它主要作了6件事：

• 若是 clienttrackingredirection 不爲空，則開啓了轉發模式；

• 找到轉發的客戶端實例；

• 若是轉發客戶端關閉了，則必須通知原客戶端；

• 若是是客戶端使用 RESP3 則發 PUSH 消息；

• 若是是轉發模式，往 TrackingChannelName 也就是 redis:invalidate 信道中發送失效消息的頭部信息；

• 發送鍵等信息。