老司機帶你玩轉面試（3）：Redis 高可用之主從模式

前文回顧

建議前面文章沒看過的同學先看下前面的文章：

「老司機帶你玩轉面試（1）：緩存中間件 Redis 基礎知識以及數據持久化」

「老司機帶你玩轉面試（2）：Redis 過期策略以及緩存雪崩、擊穿、穿透」

Redis 主從模式

在生產環境使用 Redis ，完全禁止使用單機模式，單機模式風險太高，一臺機器出於某些原因掛掉，就會導致整個緩存服務死掉，所以，我們需要使用多臺機器來保證 Redis 的高可用，同時也順便提升了併發性。

對於 Redis 緩存而言，更常見的應用場景是支持讀高併發，而寫高併發的場景相對比較少（不能說沒有，只能說相對讀高併發比較少）。

因此，使用主從模式，一主多從，主負責寫，並且將數據複製到其它的 slave 節點，從節點負責讀。所有的讀請求全部走從節點。這樣也可以很輕鬆實現水平擴容，支撐讀高併發。

經典的主從模式架構圖如下：

主從同步策略：

master 和 slave 剛剛連接的時候，進行全量同步。全量同步結束後，進行增量同步。

當然，如果有需要，slave 在任何時候都可以發起全量同步。redis 策略是，無論如何，首先會嘗試進行增量同步，如不成功，要求從機進行全量同步。

全量同步：

master 執行 BGSAVE 命令，生成一個 RDB 文件，發送給 slave ， slave 加載 RDB 文件達到與 master 維持一致。

slave 連接 master 後，發送 SYNC 命令。
master 接收到 SYNC 命名後，開始執行 BGSAVE 生成 RDB 文件，並使用緩衝區記錄此後執行的所有寫命令。
master BGSAVE 執行完後，向所有 slave 發送快照文件，並在發送期間繼續記錄被執行的寫命令。
slave 收到快照文件後丟棄所有舊數據，載入收到的快照。
master 快照發送完畢後開始向 slave 發送緩衝區中的寫命令。
salve 完成對快照的載入，開始接收命令請求，並執行來自主服務器緩衝區的寫命令。
第一次全量同步完成。

增量同步

Redis 增量複製是指 slave 初始化後開始正常工作時 master 發生的寫操作同步到 slave 的過程。

增量複製的過程主要是 master 每執行一個寫命令就會向 slave 發送相同的寫命令，從服務器接收並執行收到的寫命令。

心跳信息

主從節點互相都會發送心跳信息。

master 默認每隔 10 秒發送一次心跳信息，slave 每隔 1 秒發送一個心跳信息。

注意點：

Redis 使用異步的方式將數據從 master 節點複製到 slave 節點，slave 會週期性地確認自己每次複製的數據量。
slave 做複製的時候，不會 block master 正常工作。
slave 做複製的時候，也不會 block 自己當前的查詢工作，只是查詢的時候依然會使用舊數據，等到複製完成後，需要刪除老數據加載新數據的時候纔會 block 當前的查詢工作。
slave 主要用來做橫向擴容，提升讀的吞吐量，一定程度上做到了讀的高可用。
slave 不一定要連接到 master ，也可以 slave 連接到 slave 。
slave 不會處理過期 key ，只會等待 master 過期 key。如果 master 過期了一個 key，或者通過 LRU 淘汰了一個 key，那麼會模擬一條 del 命令發送給 slave。

無磁盤化主從複製

master 節點可以在內存中直接創建 RDB 文件，然後將 RDB 文件直接發送給 salve 節點，不在自己本地落地到磁盤，這個操作只需要在配置文件中開啓 repl-diskless-sync yes 。

但是這樣做的風險會比較高，因此，強烈建議在 master 上開啓持久化服務。

如果一定要在 master 節點上設置不開啓持久化，請在確保 Redis 實例不會自動重啓。

爲啥要確保實例不會自動重啓？

下面給大家分享一個案例，這是生產環境真實發生過的事情，都是血的教訓。

一個主從結構的 Redis 集羣，當 master 沒有配置開啓數據持久化，某個時間，突然 master 節點宕機，然後自動重啓，當 master 節點自動重啓後，由於沒有開啓數據持久化，這時的 master 節點中是無數據的，當 salve 節點進行數據同步的時候，會把 salve 節點的數據也做清空操作。這時，整個主從結構的 Redis 集羣全都沒有數據，大量的請求過來發現 Redis 沒有數據，導致請求落到了 DB 上，結果是毀滅性的。

主從模式存在的問題是，它僅僅只做到了讀高可用，如果一旦 master 節點掛掉了，就沒辦法寫數據了，只剩下 slave 節點還能讀數據，但是數據同步也沒有了，只能靠人工干預進行恢復，這並不是我們想要的高可用。

我們還需要寫高可用，這就引出了 Redis 的高可用架構：哨兵模式。

簡單來講，哨兵模式就是在 master 節點不可用後，可以自發的進行主備切換，或者叫做故障轉移。

master 節點在發生故障後，整個集羣可以自動檢測，將某個 salve 自動切換成 master 節點，這種模式纔算是實現了 Redis 真正意義上的高可用。