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

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

Redis 集群模式有三種：

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

1 主從模式

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

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

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

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

如圖所示：

優(yōu)點：

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

缺點：

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

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

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

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

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

2 哨兵模式

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

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

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

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

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

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

如圖：

優(yōu)點：

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

缺點：

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

哨兵模式是部署圖

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

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

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

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

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

3 Cluster 集群模式

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

Cluster 集群結構特點：

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

優(yōu)點

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

缺點

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

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

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

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

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

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

總結

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

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