Redis 創(chuàng)始人兼核心開發(fā)者 antirez 在博客介紹了將在 Redis 6 提供的新功能 —— Client side caching（客戶端緩存）。
antirez 表示全新的 Redis 協(xié)議 RESP3 將是 Redis 6 中最重要的特性，并解釋了他為何如此急切地改進(jìn) Redis 協(xié)議，原因主要有兩個，一是因為希望能為客戶端提供更多的語義化回復(fù)（semantical replies），以開發(fā)使用舊協(xié)議難以實現(xiàn)的功能；另一個原因也是 antirez 認(rèn)為最重要的一個，實現(xiàn) Client side caching（客戶端緩存）功能。這個功能十分常見，但 Redis 尚未提供。
當(dāng)使用者需要進(jìn)行快速存儲或快速取操作時，就需要在客戶端內(nèi)存中存儲一小部分信息，這是為了降低程序獲取數(shù)據(jù)時的延遲。此功能在大規(guī)模的應(yīng)用程序上十分重要，因為數(shù)據(jù)離應(yīng)用程序越近，程序就能更快獲取到數(shù)據(jù)。
antirez 受 Ben Malec 演講的啟發(fā)，他想到可以將大部分需要頻繁存和取的數(shù)據(jù)直接放在服務(wù)器的內(nèi)存中，以便讓 Redis 為客戶端完成部分工作，并使客戶端緩存更簡單、更有效。這個就是 Client side caching（客戶端緩存）的概念。
不過這個思路有一個需要解決的問題是，如何控制數(shù)據(jù)的有效時間？在程序允許的情況下，雖然可以直接設(shè)置數(shù)據(jù)的有效時間，讓數(shù)據(jù)在一段時間后失效。但 antirez 表示，大多數(shù)的應(yīng)用程序無法接受提供過時的數(shù)據(jù)的風(fēng)險，因此必須找到更理想的方案來控制數(shù)據(jù)的失效時間。
所以 antirez 決定開發(fā)新的協(xié)議 RESP3，在協(xié)議中加入新特性來支持客戶端緩存功能，保證存儲在客戶端內(nèi)存的數(shù)據(jù)，在收到來自服務(wù)器的失效通知時才失效。
另外，當(dāng)客戶端和服務(wù)器的連接中斷時，客戶端無法接收到數(shù)據(jù)失效通知，這可能會導(dǎo)致服務(wù)出現(xiàn)問題。針對這種情況，一般的做法是重新建立客戶端和服務(wù)器之間的連接，并更新客戶端當(dāng)前的緩存。antirez 表示可以一直保持連接是最好的情況，但為了降低風(fēng)險，Redis 服務(wù)器在與客戶端斷開連接時，會將失效通知發(fā)送給其他客戶端。
這項名為"Client side caching"的功能尚未正式確定名字，最后可能會被成為"Tracking"。Redis 作者還表示在 Redis 6 候選版發(fā)布之前，這些功能都會進(jìn)行調(diào)整，希望社區(qū)能積極反饋意見。
由于 Client side caching 功能需要使用 RESP3 協(xié)議來支持實現(xiàn)，antirez 表示會想辦法通過 RESP2 協(xié)議也能啟用此功能。
