讀寫分離：

對於讀佔比較高的場景，可以通過把一部分流量分攤匯出從節點(salve) 來減輕主節點（master）壓力，同時需要主要只對主節點執行寫操作，如下圖：

當使用從節點響應讀請求時，業務端可能會遇到以下問題：

• 複製資料延遲
• 讀到過期資料
• 從節點故障

1.資料延遲

Redis 複製數的延遲由於非同步複製特性是無法避免的，延遲取決於網路頻寬和命令阻塞情況，對於無法容忍大量延遲場景，可以編寫外部監控程式監聽主從節點的複製偏移量，當延遲較大時觸發報警或者通知客戶端避免讀取延遲過高的從節點，實現邏輯如下圖：

說明如下：

1） 監控程式(monitor) 定期檢查主從節點的偏移量，主節點偏移量在info replication 的master_repl_offset 指標記錄，從節點 偏移量可以查詢主節點的slave0 欄位的offset指標，它們的差值就是主從節點延遲的位元組 量。

2）當延遲位元組量過高時，比如超過10M。監控程式觸發報警並通知客戶端從節點延遲過高。可以採用Zookeeper的監聽回撥機制實現客戶端通知。

3） 客戶端接到具體的從節點高延遲通知後，修改讀命令路由到其他從節點或主節點上。當延遲迴復後，再次通知客戶端，回覆從節點的讀命令請求。

這種方案成本較高，需要單獨修改適配Redis的客戶端類庫。

2.讀到過期資料

當主節點儲存大量設定超時的資料時，如快取資料，Redis內部需要維護過期資料刪除策略，刪除策略主要有兩種：惰性刪除和定時刪除。

惰性刪除：主節點每次處理讀取命令時，都會檢查鍵是否超時，如果超時則執行del命令刪除鍵物件那個，之後del命令也會非同步 傳送給 從節點

需要注意的是為了保證複製的一致性，從節點自身永遠不會主動刪除超時資料，如上圖。

定時刪除：

Redis主節點在內部定時任務會迴圈取樣一定數量的鍵，當發現取樣的鍵過期就執行del命令，之後再同步給從節點，如下圖

如果此時 資料的大量超時，主節點取樣速度跟不上過期速度且主節點沒有讀取過期鍵的操作，那麼從節點將無法收到del命令，這時在從節點 上可以讀取到已經超時的資料。Redis在3.2 版本解決了這個問題，從節點 讀取資料之前會檢查鍵的過期時間來決定是否返回資料，可以升級到3.2版本來規避這個問題。

3.從節點故障問題

對於從節點故障問題，需要在客戶端維護可用從節點列表，當從節點故障時立刻切換到其他從節點或主節點上。

建議大家在做讀寫分離時，可以考慮使用Redis Cluster等分散式解決方案