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 協議也能啟用此功能。
[admin
]
來源：OsChina
連結：https://www.oschina.net/news/108059/client-side-caching-in-redis6
Redis 6 將採用全新協議 RESP3，以提供客戶端緩存功能已經有232次圍觀
