字節(jié)一面：Redis主節(jié)點的Key已過期，但從節(jié)點依然讀到過期數(shù)據(jù)....
[導讀]我們知道，大部分的業(yè)務(wù)場景都是讀多寫少，為了利用好這個特性，提升Redis集群系統(tǒng)的吞吐能力，通常會采用主從架構(gòu)、讀寫分離如上圖所示：其中Master節(jié)點：負責業(yè)務(wù)的寫操作Slave節(jié)點：實時同步Master節(jié)點的數(shù)據(jù)，提供讀能力為了提高吞吐量，采用一主多從的架構(gòu)，將業(yè)務(wù)的讀壓力...
我們知道，大部分的業(yè)務(wù)場景都是讀多寫少，為了利用好這個特性，提升Redis集群系統(tǒng)的吞吐能力，通常會采用
主從架構(gòu)、讀寫分離
如上圖所示：其中
- Master節(jié)點：負責業(yè)務(wù)的寫操作
- Slave節(jié)點：實時同步Master節(jié)點的數(shù)據(jù)，提供讀能力
為了提高吞吐量，采用一主多從的架構(gòu)，將業(yè)務(wù)的讀壓力分攤到多臺服務(wù)器上上述方案，看似合理，但其實可能存在一定隱患！
一、拉取過期數(shù)據(jù)
Redis性能高主要得益于純內(nèi)存操作，但內(nèi)存存儲介質(zhì)的成本過高，所以數(shù)據(jù)的存儲有一定的約束。
通常會設(shè)置過期時間，對于一些使用不是很頻繁的數(shù)據(jù)，會定期刪除，提高資源的利用率。刪除過期數(shù)據(jù)，Redis提供了兩種策略：1、惰性刪除。也稱被動刪除，當數(shù)據(jù)過期后，并不會馬上刪除。而是等到有請求訪問時，對數(shù)據(jù)檢查，如果數(shù)據(jù)過期，則刪除數(shù)據(jù)。優(yōu)點：不需要單獨啟動額外的掃描線程，減少了CPU資源的損耗。2、定期刪除。每隔一段時間，
缺點：大量的過期數(shù)據(jù)滯留內(nèi)存中，需要主動觸發(fā)、檢查、刪除，否則會一直占用內(nèi)存資源。
默認100ms，Redis會隨機挑選一定數(shù)量的Key，檢查是否過期，并將過期的數(shù)據(jù)刪除。你可能會為問了，既然Redis有過期數(shù)據(jù)刪除策略，那為什么還會拉取到已經(jīng)過期的數(shù)據(jù)呢？
這要從
主從同步講起了，我們先來看張流程圖
當客戶端往主庫寫入數(shù)據(jù)后，并設(shè)置了過期時間，數(shù)據(jù)會以異步方式同步給從庫。1、如果此時讀主庫，數(shù)據(jù)已經(jīng)過期，主庫的
惰性刪除會發(fā)揮作用，主動觸發(fā)刪除操作，客戶端不會拿到已過期數(shù)據(jù)2、但是如果讀從庫，則有可能拿到過期數(shù)據(jù)。原因有兩個原因一：跟 Redis 的版本有關(guān)系，Redis 3.2 之前版本，讀從庫并不會判斷數(shù)據(jù)是否過期，所以有可能返回過期數(shù)據(jù)。解決方案：升級Redis的版本，至少要3.2 以上版本，讀從庫，如果數(shù)據(jù)已經(jīng)過期，則會過濾并返回空值。特別注意：
此時同步過來的數(shù)據(jù)，雖然已經(jīng)過期，但本著誰生產(chǎn)誰維護的原則，從庫并不會主動刪除同步的數(shù)據(jù)，需要依賴于主節(jié)點同步過來的key刪除命令。
原因二：跟過期時間的設(shè)置方式有關(guān)系，我們一般采用
EXPIRE 和 PEXPIRE，表示從執(zhí)行命令那個時刻開始，往后延長 ttl 時間。嚴重依賴于 開始時間 從什么時候算起。- EXPIRE：單位為秒
- PEXPIRE：單位為毫秒
如上圖所示，簡單描述下過程：- 主庫在 t1 時刻寫入一個帶過期時間的數(shù)據(jù)，數(shù)據(jù)的有效期一直到 t3
- 由于網(wǎng)絡(luò)原因、或者緩存服務(wù)器的執(zhí)行效率，從庫的命令并沒有立即執(zhí)行。一直等到了 t2 才開始執(zhí)行， 數(shù)據(jù)的有效期則會延后到 t5
- 如果，此時客戶端訪問從庫，發(fā)現(xiàn)數(shù)據(jù)依然處于有效期內(nèi)，可以正常使用
EXPIREAT 和 PEXPIREAT，相對簡單，表示過期時間為一個具體的時間點。避免了對開始時間從什么時候算起的依賴。- EXPIREAT：單位為秒
- PEXPIREAT：單位為毫秒
特別注意：
EXPIREAT 和 PEXPIREAT 設(shè)置的是時間點，所以要求主從節(jié)點的時鐘保持一致，需要與NTP 時間服務(wù)器保持時鐘同步。
主從同步，除了
讀從庫可能拉取到過期數(shù)據(jù)，還可能遇到數(shù)據(jù)一致性問題。繼續(xù)往下看二、主從數(shù)據(jù)不一致
解釋下，什么是主從數(shù)據(jù)不一致？指客戶端從庫中讀取到的值與主庫中讀取的值不一致！
如圖所示：- 客戶端寫入主庫，值為100
- 然后，主庫將值100 同步給 從庫
- 接著，客戶端又訪問主庫，將值更新為 200
- 由于主從同步是異步進行的，有一定延遲，假如最新數(shù)據(jù)還沒有同步到從庫，那么從庫讀取的就不是最新值。
info replication命令 ，查看主庫接收寫命令的進度信息（master_repl_offset），從庫的復(fù)制寫命令的進度信息（slave_repl_offset）
master_repl_offset - slave_repl_offset得到從庫與主庫間的復(fù)制進度差我們可以開發(fā)一個監(jiān)控程序，定時拉取主從服務(wù)器的進度信息，計算進度差值。如果超過我們設(shè)置的閾值，則通知客戶端斷開從庫的連接，全部訪問主庫，一定程度上減少數(shù)據(jù)不一致情況。
待同步進度跟上后，我們再恢復(fù)客戶端與從節(jié)點的讀操作。
下載文檔
