字節(jié)一面：Redis主節(jié)點的Key已過期，但從節(jié)點依然讀到過期數(shù)據(jù)....

時間：2021-11-15 14:30:59

關鍵字：節(jié)點

手機看文章

掃描二維碼
隨時隨地手機看文章

[導讀]我們知道，大部分的業(yè)務場景都是讀多寫少，為了利用好這個特性，提升Redis集群系統(tǒng)的吞吐能力，通常會采用主從架構、讀寫分離如上圖所示：其中Master節(jié)點：負責業(yè)務的寫操作Slave節(jié)點：實時同步Master節(jié)點的數(shù)據(jù)，提供讀能力為了提高吞吐量，采用一主多從的架構，將業(yè)務的讀壓力...

我們知道，大部分的業(yè)務場景都是讀多寫少，為了利用好這個特性，提升Redis集群系統(tǒng)的吞吐能力，通常會采用主從架構、讀寫分離

如上圖所示：其中

Master節(jié)點：負責業(yè)務的寫操作
Slave節(jié)點：實時同步Master節(jié)點的數(shù)據(jù)，提供讀能力

為了提高吞吐量，采用一主多從的架構，將業(yè)務的讀壓力分攤到多臺服務器上

上述方案，看似合理，但其實可能存在一定隱患！

一、拉取過期數(shù)據(jù)

Redis性能高主要得益于純內存操作，但內存存儲介質的成本過高，所以數(shù)據(jù)的存儲有一定的約束。

通常會設置過期時間，對于一些使用不是很頻繁的數(shù)據(jù)，會定期刪除，提高資源的利用率。

刪除過期數(shù)據(jù)，Redis提供了兩種策略：

1、惰性刪除。

也稱被動刪除，當數(shù)據(jù)過期后，并不會馬上刪除。而是等到有請求訪問時，對數(shù)據(jù)檢查，如果數(shù)據(jù)過期，則刪除數(shù)據(jù)。

優(yōu)點：不需要單獨啟動額外的掃描線程，減少了CPU資源的損耗。

缺點：大量的過期數(shù)據(jù)滯留內存中，需要主動觸發(fā)、檢查、刪除，否則會一直占用內存資源。

2、定期刪除。每隔一段時間，默認100ms，Redis會隨機挑選一定數(shù)量的Key，檢查是否過期，并將過期的數(shù)據(jù)刪除。

你可能會為問了，既然Redis有過期數(shù)據(jù)刪除策略，那為什么還會拉取到已經過期的數(shù)據(jù)呢？

這要從主從同步講起了，我們先來看張流程圖

當客戶端往主庫寫入數(shù)據(jù)后，并設置了過期時間，數(shù)據(jù)會以異步方式同步給從庫。

1、如果此時讀主庫，數(shù)據(jù)已經過期，主庫的惰性刪除會發(fā)揮作用，主動觸發(fā)刪除操作，客戶端不會拿到已過期數(shù)據(jù)

2、但是如果讀從庫，則有可能拿到過期數(shù)據(jù)。原因有兩個

原因一：

跟 Redis 的版本有關系，Redis 3.2 之前版本，讀從庫并不會判斷數(shù)據(jù)是否過期，所以有可能返回過期數(shù)據(jù)。

解決方案：

升級Redis的版本，至少要3.2 以上版本，讀從庫，如果數(shù)據(jù)已經過期，則會過濾并返回空值。

特別注意：

此時同步過來的數(shù)據(jù)，雖然已經過期，但本著誰生產誰維護的原則，從庫并不會主動刪除同步的數(shù)據(jù)，需要依賴于主節(jié)點同步過來的key刪除命令。

原因二：

跟過期時間的設置方式有關系，我們一般采用 EXPIRE 和 PEXPIRE，表示從執(zhí)行命令那個時刻開始，往后延長 ttl 時間。嚴重依賴于 開始時間 從什么時候算起。

EXPIRE：單位為秒
PEXPIRE：單位為毫秒

如上圖所示，簡單描述下過程：

主庫在 t1 時刻寫入一個帶過期時間的數(shù)據(jù)，數(shù)據(jù)的有效期一直到 t3
由于網(wǎng)絡原因、或者緩存服務器的執(zhí)行效率，從庫的命令并沒有立即執(zhí)行。一直等到了 t2 才開始執(zhí)行，數(shù)據(jù)的有效期則會延后到 t5
如果，此時客戶端訪問從庫，發(fā)現(xiàn)數(shù)據(jù)依然處于有效期內，可以正常使用

解決方案：

可以采用Redis的另外兩個命令，EXPIREAT 和 PEXPIREAT，相對簡單，表示過期時間為一個具體的時間點。避免了對開始時間從什么時候算起的依賴。