Redis的哨兵模式

什么是哨兵模式

Redis提供了哨兵的命令，哨兵是一個獨立的進程，作為進程，它會獨立運行。其原理是哨兵通過發送命令，等待Redis服務器響應，從而監控運行的多個Redis實例。

哨兵的工作原理

每個哨兵會向其它哨兵、master、slave定時發送消息，以確認對方是否”活”著，如果發現對方在指定時間(可配置)內未回應，則暫時認為對方主觀下線。若“哨兵群”中的半數sentinel，都報告某一master沒響應，系統才認為該master"徹底死亡"，即客觀下線。通過一定的vote算法，從剩下的slave節點中，選一臺提升為master，然后自動修改相關配置。

實際上哨兵只是一個運行在特殊模式下的 Redis 服務器，你可以在啟動一個普通 Redis 服務器時通過給定 --sentinel 選項來啟動哨兵(sentinel)。

哨兵的任務

• 監控：哨兵(sentinel) 會不斷地檢查你的Master和Slave是否運作正常。
• 提醒：當被監控的某個 Redis出現問題時, 哨兵(sentinel) 可以通過 API 向管理員或者其他應用程序發送通知。
• 自動故障遷移：當一個Master不能正常工作時，哨兵(sentinel)會開始一次自動故障遷移操作,它會將失效Master的其中一個Slave升級為新的Master,并讓失效Master的其他Slave改為復制新的Master;當客戶端試圖連接失效的Master時,集群也會向客戶端返回新Master的地址,使得集群可以使用Master代替失效Master。

哨兵的作用

• 通過發送命令，讓Redis服務器返回監控其運行狀態，包括主服務器和從服務器。
• 當哨兵監測到master宕機，會自動將slave切換成master，然后通過發布訂閱模式通知其他的從服務器，修改配置文件，讓它們切換主機。

Redis集群

本篇文章對Redis集群的講解基于Redis官方提供的Redis Cluster模型來進行。

什么是Redis集群

Redis集群提供一種方式自動將數據分布在多個Redis節點上。Redis 集群通過分區來提供一定程度的可用性： 即使集群中有一部分節點失效或者無法進行通訊， 集群也可以繼續處理命令請求。

數據分片

Redis 集群使用數據分片而非一致性哈希來實現： 一個 Redis 集群包含 16384 個哈希槽， 數據庫中的每個鍵都屬于這 16384 個哈希槽的其中一個， 集群使用公式 CRC16(key) % 16384 來計算鍵 key 屬于哪個槽。集群中的每個節點負責處理一部分哈希槽。

這種將哈希槽分布到不同節點的做法使得用戶可以很容易地向集群中添加或者刪除節點。 假設現在集群中有A,B,C,D四個節點，如果我們現在想將新節點E添加到集群中，只需要將A,B,C,D的某些槽移動到E就可以了。同理，如果我們要從集群中移除節點 A ， 那么集群只需要將節點 A 中的所有哈希槽移動到B,C,D ， 然后再移除空白（不包含任何哈希槽）的節點 A 就可以了。

因為將一個哈希槽從一個節點移動到另一個節點不會造成節點阻塞， 所以無論是添加新節點還是移除已存在節點， 又或者改變某個節點包含的哈希槽數量， 都不會造成集群下線。

集群的高可用性

集群支持主從復制和主節點的自動故障轉移（與哨兵類似）；當任一節點發生故障時，集群仍然可以對外提供服務。

集群狀態

當每個槽都被分配完畢，集群就處于上線狀態，否則就處于下線狀態。

ASK錯誤

當客戶端向節點發送關于節點key的命令的時候，若發現節點key不存在于源節點的數據庫且源節點正在遷移槽i，則會向客戶端返回一個ASK錯誤。當客戶端收到ASK錯誤后，從中讀取目標節點的地址信息，并向目標節點重新發送請求。

集群方案設計

設計集群方案時，至少要考慮以下因素：

• 高可用要求：根據故障轉移的原理，至少需要3個主節點才能完成故障轉移，且3個主節點不應在同一臺物理機上；每個主節點至少需要1個從節點，且主從節點不應在一臺物理機上；因此高可用集群至少包含6個節點。
• 數據量和訪問量：估算應用需要的數據量和總訪問量(考慮業務發展，留有冗余)，結合每個主節點的容量和能承受的訪問量(可以通過benchmark得到較準確估計)，計算需要的主節點數量。
• 節點數量限制：Redis官方給出的節點數量限制為1000，主要是考慮節點間通信帶來的消耗。在實際應用中應盡量避免大集群；如果節點數量不足以滿足應用對Redis數據量和訪問量的要求，可以考慮：(1)業務分割，大集群分為多個小集群；(2)減少不必要的數據；(3)調整數據過期策略等。
• 適度冗余：Redis可以在不影響集群服務的情況下增加節點，因此節點數量適當冗余即可，不用太大。

Redis集群的優勢

• 可以將數據自動切分到多個節點
• 當集群中的一部分節點失效或者無法進行通訊時， 仍然可以繼續處理命令請求的能力

集群存在的一些不足

• 涉及多個key的操作通常是不被支持的。舉例來說，當兩個set映射到不同的redis實例上時，你就不能對這兩個set執行交集操作。
• 涉及多個key的redis事務不能使用。
• 不能保證集群內的數據均衡。分區的粒度是key，如果某個key的值是巨大的set、list，無法進行拆分。
• 增加或刪除容量也比較復雜。redis集群需要支持在運行時增加、刪除節點的透明數據平衡的能力。

對Redis高可用性的總結

我們之前Redis系列的文章提到了持久化、主從復制、哨兵模式和Redis集群等概念，下面我們對其進行總結：

• 持久化：持久化是最簡單的高可用方法，主要作用是數據備份，即將數據存儲在硬盤，保證數據不會因進程退出而丟失。
• 復制：復制是高可用Redis的基礎，哨兵和集群都是在復制基礎上實現高可用的。復制主要實現了數據的多機備份，以及對于讀操作的負載均衡和簡單的故障恢復。缺陷：故障恢復無法自動化；寫操作無法負載均衡；存儲能力受到單機的限制。
• 哨兵：在復制的基礎上，哨兵實現了自動化的故障恢復。缺陷：寫操作無法負載均衡；存儲能力受到單機的限制。
• 集群：通過集群，Redis解決了寫操作無法負載均衡，以及存儲能力受到單機限制的問題，實現了較為完善的高可用方案。

參考：Redis哨兵（Sentinel）模式
redis主從復制下哨兵模式—選舉原理
Redis集群的原理和搭建
深入學習Redis（5）：集群
深入學習Redis（4）：哨兵

總結

以上是生活随笔為你收集整理的Redis(3)--哨兵模式，集群的全部內容，希望文章能夠幫你解決所遇到的問題。

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