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