Redis 6將使用全新協定RESP3提供客戶端快取功能

Redis之父Salvatore Sanfilippo在自己的部落格，解釋Redis 6中新版的Redis協定RESP3，是他認為新版Redis最重要的改變，因為能為客戶端提供更多的語意回覆，用來開發舊協定難以實作的功能，像是其他資料庫都有，但Redis還沒提供的客戶端快取（Client Side Caching）功能。

當使用者需要進行快速儲存或是快速快取操作時，便需要在客戶端記憶體中儲存一小部分訊息，這是為了較少應用程式擷取資料時的延遲，這個想法在大規模應用上特別重要，因為擺放的資料越靠近應用程式，應用程式就能越快取得需要的資料，Salvatore Sanfilippo提到，網路記憶體系統的下一步，就是要將大部分可以存取的資料，直接放在應用程式伺服器的記憶體中，這個概念稱為客戶端快取。

但這個做法有一個需要解決的問題是，控制資料的有效性的方法，在應用可以允許的狀況下，雖然可以直接設定快取資料的有效時間，讓資料在一段時間後失效，但Salvatore Sanfilippo提到，大多數的應用程式無法接受提供過時的資料的風險，因此必須要找到一個更積極的方法，讓存在客戶端記憶體的資料失效。為此Salvatore Sanfilipp才在新版的Redis協定RESP3，加入了新功能來支援客戶端快取，讓儲存在客戶端記憶體資料，在客戶端收到來自伺服器的失效訊息時失效。

另外，當客戶端與伺服器端的連接中斷，則客戶端收不到資料失效訊息，這可能導致應用服務發生問題，一般的做法是重新建立連結，並更新客戶端目前的快取，Salvatore Sanfilippo提到，可以一直保持連線確保失效訊息傳遞順暢是最好的情況，但是為了減少過時資料產生的風險，Redis伺服器還會在與客戶端連結中斷時，將資料失效訊息轉送至其他客戶端。

客戶端快取功能在不少資料庫都有提供，但在Redis上遲遲尚未支援，而終於在Redis 6將會加入輔助伺服器端的客戶端快取，這項功能的名稱尚未完全確定，最後可能會被改稱為追蹤（Tracking）。目前客戶端快取的功能只在Redis的不穩定版中提供，Salvatore Sanfilippo提到，在Redis 6候選版釋出前，這些功能還能夠調整，希望社群可以踴躍回饋想法，而由於客戶端快取只能在RESP3支援，他也正設法讓RESP2能夠啟用該功能。