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

前文回顧

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

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

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

Redis 主從模式

在生產環境使用 Redis ，徹底禁止使用單機模式，單機模式風險過高，一臺機器出於某些緣由掛掉，就會致使整個緩存服務死掉，因此，咱們須要使用多臺機器來保證 Redis 的高可用，同時也順便提高了併發性。

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

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

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

主從同步策略：

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

固然，若是有須要，slave 在任什麼時候候均可以發起全量同步。redis 策略是，不管如何，首先會嘗試進行增量同步，如不成功，要求從機進行全量同步。

全量同步：

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

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

增量同步

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 真正意義上的高可用。

參考

www.cnblogs.com/daofaziran/…

您的掃碼關注，是對小編堅持原創的最大鼓勵：）