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能夠啟用該功能。


Advertisement

更多 iThome相關內容