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

如上圖所示：其中

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

為了提高吞吐量，采用一主多從的架構(gòu)，將業(yè)務(wù)的讀壓力分?jǐn)偟蕉嗯_服務(wù)器上

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

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

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

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

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

1、惰性刪除。

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

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

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

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

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

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

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

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

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

原因一：

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

解決方案：

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

特別注意：

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

原因二：

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

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

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

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

解決方案：

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

• EXPIREAT：單位為秒
• PEXPIREAT：單位為毫秒

特別注意：

EXPIREAT 和 PEXPIREAT 設(shè)置的是時(shí)間點(diǎn)，所以要求主從節(jié)點(diǎn)的時(shí)鐘保持一致，需要與NTP 時(shí)間服務(wù)器保持時(shí)鐘同步。

主從同步，除了讀從庫可能拉取到過期數(shù)據(jù)，還可能遇到數(shù)據(jù)一致性問題。

繼續(xù)往下看

二、主從數(shù)據(jù)不一致

解釋下，什么是主從數(shù)據(jù)不一致？指客戶端從庫中讀取到的值與主庫中讀取的值不一致！

如圖所示：

• 客戶端寫入主庫，值為100
• 然后，主庫將值100 同步給 從庫
• 接著，客戶端又訪問主庫，將值更新為 200
• 由于主從同步是異步進(jìn)行的，有一定延遲，假如最新數(shù)據(jù)還沒有同步到從庫，那么從庫讀取的就不是最新值。

從庫同步落后的原因主要有兩個(gè)：

1、主從服務(wù)器間的網(wǎng)絡(luò)傳輸可能有延遲

2、從庫已經(jīng)收到主庫的命令，由于是單線程執(zhí)行，前面正在處理一些耗時(shí)的命令（如：pipeline批處理），無法及時(shí)同步執(zhí)行。

解決方案：

1、主從服務(wù)器盡量部署在同一個(gè)機(jī)房，并保持服務(wù)器間的網(wǎng)絡(luò)良好通暢

2、監(jiān)控主從庫間的同步進(jìn)度，通過info replication命令 ，查看主庫接收寫命令的進(jìn)度信息（master_repl_offset），從庫的復(fù)制寫命令的進(jìn)度信息（slave_repl_offset）

master_repl_offset - slave_repl_offset

得到從庫與主庫間的復(fù)制進(jìn)度差

我們可以開發(fā)一個(gè)監(jiān)控程序，定時(shí)拉取主從服務(wù)器的進(jìn)度信息，計(jì)算進(jìn)度差值。如果超過我們設(shè)置的閾值，則通知客戶端斷開從庫的連接，全部訪問主庫，一定程度上減少數(shù)據(jù)不一致情況。

待同步進(jìn)度跟上后，我們再恢復(fù)客戶端與從節(jié)點(diǎn)的讀操作。