Redis創始人兼核心開發者antirez在博客介紹了將在Redis 6提供的新功能——  Client side caching（客戶端緩存）。antirez表示全新的Redis協議RESP3將是Redis 6中最重要的特性，並解釋了他為何如此急切地改進Redis協議，原因主要有兩個，一是因為希望能為客戶端提供更多的語義化回复（semantical replies），以開發使用舊協議難以實現的功能；

另一個原因也是antirez認為最重要的一個，實現Client side caching（客戶端緩存）功能。這個功能十分常見，但Redis尚未提供。

當使用者需要進行快速存儲或快速取操作時，就需要在客戶端內存中存儲一小部分信息，這是為了降低程序獲取數據時的延遲。此功能在大規模的應用程序上十分重要，因為數據離應用程序越近，程序就能更快獲取到數據。

antirez受Ben Malec演講的啟發，他想到可以將大部分需要頻繁存和取的數據直接放在服務器的內存中，以便讓Redis為客戶端完成部分工作，並使客戶端緩存更簡單、更有效。這個就是Client side caching（客戶端緩存）的概念。

不過這個思路有一個需要解決的問題是，如何控制數據的有效時間？在程序允許的情況下，雖然可以直接設置數據的有效時間，讓數據在一段時間後失效。但antirez 表示，大多數的應用程序無法接受提供過時的數據的風險，因此必須找到更理想的方案來控制數據的失效時間。

所以 antirez 決定開發新的協議 RESP3，在協議中加入新特性來支持客戶端緩存功能，保證存儲在客戶端內存的數據，在收到來自服務器的失效通知時才失效。

另外，當客戶端和服務器的連接中斷時，客戶端無法接收到數據失效通知，這可能會導致服務出現問題。針對這種情況，一般的做法是重新建立客戶端和服務器之間的連接，並更新客戶端當前的緩存。antirez 表示可以一直保持連接是最好的情況，但為了降低風險，Redis 服務器在與客戶端斷開連接時，會將失效通知發送給其他客戶端。

這項名為”Client side caching”的功能尚未正式確定名字，最後可能會被成為”Tracking”。Redis 作者還表示在Redis 6 候選版發布之前，這些功能都會進行調整，希望社區能積極反饋意見。

由於 Client side caching 功能需要使用 RESP3 協議來支持實現，antirez 表示會想辦法通過 RESP2 協議也能啟用此功能。