Redis 是如何做到高可用的呢？

它主要通過支持主從模式、哨兵模式、集群模式這三種模式，來滿足不同業務特點和可用等級的需求。 其中，主從模式部署最簡單，用得也最多，集群模式比較復雜，但可用性最高。

Redis 集群模式有三種：

• 主從模式
• 哨兵模式
• Cluster 集群模式

1 主從模式

為了 Redis 服務避免單點故障，通常的做法是將 Redis 數據復制多個副本以部署在不同的服務器上。這樣即使有一臺服務器出現故障，其他服務器依然可以繼續提供服務。為此，Redis 提供了復制（ replication ）功能，可以實現當一臺數據庫中的數據更新后，自動將更新的數據同步到其他數據庫上。

Redis 服務器分為兩類：一類是主數據庫（Master），另一類是從數據庫（Slave）。

主數據庫可以進行讀寫操作，當寫操作導致數據變化時會自動將數據同步給從數據庫。

從數據庫一般是只讀的，并接受主數據庫同步過來的數據。一個主數據庫可以擁有多個從數據庫，而一個從數據庫只能擁有一個主數據庫。

如圖所示：

優點：

1. 一個主，可以有多個從，并以非阻塞的方式完成數據同步；
2. 從服務器提供讀服務，分散主服務的壓力，實現讀寫分離；
3. 從服務器之前可以彼此連接和同步請求，減少主服務同步壓力；

缺點：

1. 不具備容錯和恢復功能，主服務存在單點風險；
2. Redis 的主從復制采用全量復制，需要服務器有足夠的空余內存；
3. 主從模式較難支持在線擴容；

主從模式比較簡單，可部署多個節點，其中一個作為 Master 節點，剩下的作為 Slave 節點。它的示意圖如下：

在主從模式里，客戶端同時連接 Master 節點和 Slave 節點，寫操作通過 Master 節點執行，并將結果同步給 Slave 節點，讀操作通過 Slave 節點執行。假如 Master 節點掛了，不影響讀操作，我們可以通過手動修改配置將某個 Slave 節點提升為 Master 節點，重新提供寫能力。

主從模式最大的優點是部署簡單，最少兩個節點便可以構成主從模式，并且可以通過讀寫分離避免讀和寫同時不可用。不過，一旦 Master 節點出現故障，主從節點就無法自動切換，直接導致 SLA 下降。所以，主從模式一般適合業務發展初期，并發量低，運維成本低的情況。

后來，為了避免主從無法自動切換的問題，又出現了一種新模式——哨兵模式，它是主從模式的升級。

2 哨兵模式

Redis 提供的 sentinel（哨兵）機制，通過 sentinel 模式啟動 redis 后，自動監控 Master/Slave 的運行狀態，基本原理是：心跳機制 + 投票裁決。

簡單來說，哨兵的作用就是監控 Redis 系統的運行狀況。它的功能包括以下兩個：

1. 監控主數據庫和從數據庫是否正常運行；
2. 主數據庫出現故障時自動將從數據庫轉換為主數據庫；

哨兵模式主要有下面幾個內容：

• 監控（ Monitoring）：Sentinel 會定期檢查主從服務器是否處于正常工作狀態。
• 提醒（ Notification ）：當被監控的某個 Redis 服務器出現異常時，Sentinel 可以通過 API 向管理員或者其他應用程序發送通知。
• 自動故障遷移（Automatic failover）：當一個主服務器不能正常工作時，Sentinel 會開始一次自動故障遷移操作，它會將失效主服務器的其中一個從服務器升級為新的主服務器，并讓失效主服務器的其他從服務器改為復制新的主服務器；當客戶端試圖連接失效的主服務器時，集群也會向客戶端返回新主服務器的地址， 使得集群可以使用新主服務器代替失效服務器。

Redis Sentinel 是一個分布式系統，你可以在一個架構中運行多個 Sentinel 進程（ progress ）。

如圖：

優點：

1. 哨兵模式主從可以切換，具備基本的故障轉移能力；
2. 哨兵模式具備主從模式的所有優點；

缺點：

1. 哨兵模式也很難支持在線擴容操作；
2. 集群的配置信息管理比較復雜；

哨兵模式是部署圖

相比主從模式，哨兵模式新增了獨立部署的節點——哨兵節點（Sentinel）。

這些節點雖然不參與數據處理，但它們會像哨兵一樣負責監控 Master 和 Slave 的狀態及拓撲關系，并把主從關系信息提供給客戶端。客戶端在連接 Redis 的時候，會先連接哨兵節點，獲取 Master 和 Slave 信息，然后再連接 Master 和 Slave。

在三種模式當中，哨兵模式是 Redis 官方推薦的高可用模式，那它是如何做到高可用的呢？

• 首先，哨兵集群會通過 Ping 和 Info 請求監控所有 Redis 節點的狀態，并且哨兵集群內會選舉出 Leader 節點。
• 當 Master 節點掛了后，哨兵集群內部會進行投票，如果超過半數節點確認 Master 節點掛了，則會由哨兵集群的 Leader 節點選擇一個 Slave 節點進行主從切換。
• 最后，哨兵集群會將新的主從信息通知給客戶端，讓客戶端連接到新的 Master 和 Slave 節點上。

哨兵模式適合讀請求遠多于寫請求的業務場景，比如在秒殺系統中用來緩存活動信息。 如果寫請求較多，當集群 Slave 節點數量多了后，Master 節點同步數據的壓力會非常大。怎么辦呢？為了解決寫請求較多的業務場景， Redis 又提供了集群模式。

3 Cluster 集群模式

Redis Cluster 是一種服務器 Sharding 技術，3.0 版本開始正式提供。采用無中心結構，每個節點保存數據和整個集群狀態,每個節點都和其他所有節點連接。如圖所示：

Cluster 集群結構特點：

1. Redis Cluster 所有的物理節點都映射到 [ 0-16383 ] slot 上（不一定均勻分布），Cluster 負責維護節點、桶、值之間的關系；
2. 在 Redis 集群中放置一個 key-value 時，根據 CRC16(key) mod 16384 的值，從之前劃分的 16384 個桶中選擇一個；
3. 所有的 Redis 節點彼此互聯（PING-PONG 機制），內部使用二進制協議優化傳輸效率；
4. 超過半數的節點檢測到某個節點失效時則判定該節點失效；
5. 使用端與 Redis 節點鏈接,不需要中間 proxy 層，直接可以操作，使用端不需要連接集群所有節點，連接集群中任何一個可用節點即可。

優點

1. 無中心架構，節點間數據共享，可動態調整數據分布；
2. 節點可動態添加刪除，擴展性比較靈活；
3. 部分節點異常，不影響整體集群的可用性。

缺點

1. 集群實現比較復雜；
2. 批量操作指令（ mget、mset 等）支持有限；
3. 事務操作支持有限。

集群模式具體是怎么部署的呢？請看下圖：
為了避免單一節點負載過高導致不穩定，集群模式采用一致性哈希算法將 Key分布到各個節點上。其中，每個 Master 節點后跟若干個 Slave節點，用于出現故障時做主備切換。

在這種模式下，Master 節點可以同時處理讀和寫請求。具體來說，客戶端可以連接任意 Master 節點，集群內部會按照不同 key 將請求轉發到不同的 Master 節點。當然，為了減少 Master 內部轉發請求的壓力，也可以選擇在客戶端連接所有 Master 節點，直接在客戶端將請求哈希到對應的 Master 節點。

集群模式是如何實現高可用的呢？集群內部節點之間會互相定時探測對方是否存活，如果多數節點判斷某個節點掛了，則會將其踢出集群，然后從 Slave 節點中選舉出一個節點替補掛掉的 Master 節點。

雖然集群模式避免了 Master 單節點的問題，但集群內同步數據時會占用一定的帶寬。所以，只有在寫操作比較多的情況下人們才使用集群模式，其他大多數情況，使用哨兵模式都能滿足需求。

備注：部分來源于網絡，若侵權請聯系刪除

總結

以上是生活随笔為你收集整理的Redis 高级特性（5）— 集群模式（主从模式、哨兵模式、cluster 集群模式）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。