Redis高可用方案

一.名詞解釋

二.主從復制

Redis主從復制模式可以將主節點的數據同步給從節點，從而保障當主節點不可達的情況下，從節點可以作為

後備頂上來，並且可以保障數據盡量不丟失（主從復制可以保障最終一致性）。第二，從節點可以擴展主節點的讀

能力，一旦主節點不能支持大規模並發量的讀操作，從節點可以在一定程度上分擔主節點的壓力。

主從復制面臨的問題：

1.當主節點發生故障的時候，需要手動的將一個從節點晉升為主節點，同時通知應用方修改主節點地址並重啟

應用，同時需要命令其它從節點復制新的主節點，整個過程需要人工幹預。

2.主節點的寫能力受到單機的限制。

3.主節點的存儲能力受到單機的限制。

三. 原始的故障遷移

1.主節點發生故障後，客戶端連接主節點失敗，兩個從節點與主節點連接失敗造成復制中斷。

2.如果主節點無法正常啟動，需要選出一個從節點(slave-1),對其執行slaveof no one命令使其成為新的主節

3.原來的從節點（slave-1）成為新的主節點後，更新應用方的主節點信息，重新啟動應用方。

4.客戶端命令另一個從節點（slave-2）去復制新的主節點

5.待原來的主節點恢復後，讓它去復制新的主節點

四.Redis Sentinel的高可用

當主節點出現故障時，Redis Sentinel能自動完成故障發現和故障轉移，並通知應用方，從而實現真正的高可用。

RedisSentine是一個分布式架構，其中包含若幹個Sentinel節點和Redis數據節點，每個Sentinel節點會對數據節點和

其余Sentinel節點進行監控，當它發現節點不可達時，會對節點做下線標識。如果被標識的是“主節點”，它還會和

其他的Sentinel節點進行“協商”，當大多數Sentinel節點都認為主節點不可達時，它們會選舉一個Sentinel節點來完

成自動故障轉移的工作，同時會將這個變化實時通知給Redis應用方。整個過程是自動的，不需要人工幹預，解決了

Redis的高可用問題。

Redis Sentinel包含了若幹個Sentinel節點，這樣做也帶來了兩個好處：

1. 對節點的故障判斷是由多個Sentinel節點共同完成，這樣可以有效的防止誤判。

2. Sentinel節點集合是由若幹個Sentinel節點組成的，這樣即使個別Sentinel節點不可用，整個Sentinel節點集合依

然是健壯的。

Redis Sentinel具有以下幾個功能：

1.監控：Sentinel會定期檢測Redis數據節點、其余Sentinel節點是否可到達

2.通知：Sentinel會將故障轉移的結果通知給應用方。

3.主節點故障轉移：實現從節點晉升為主節點並維護後續正確的主從關系。

4.配置提供者：在RedisSentinel結構中，客戶端在初始化的時候連接的是Sentinel節點集合，從中獲取主節點信息。

五. Redis Sentinel拓撲結構

六. Redis Sentinel節點發現和監控機制

Redis Sentinel通過三個定時監控任務完成對各個節點的發現和監控：

1.每隔10秒，每個Sentinel會向主節點和從節點發送info命令獲取最新的拓撲結構。

2.每隔2秒，每個Sentinel節點會向Redis數據節點的_sentinel_：hello頻道上發送該Senitnel節點對於主節點的判斷。

以及當前Sentinel節點的信息，同時每個Sentinel節點也會訂閱該頻道，來了解其他Sentinel節點以及他們對主節

點的判斷。這個定時任務可以完成以下兩個工作：

（1）發現新的Sentinel節點：通過訂閱主節點的_Sentinel_:hello了解其他Sentinel節點信息。如果是新加入的

Sentinel節點，將該Sentinel節點信息保存起來，並與改Sentinel節點創建連接

（2）Sentinel節點之間交換主節點狀態，作為後面客觀下線以及領導者選舉的依據

3.每隔1秒，每個Sentinel節點會向主節點、從節點、其余Sentinel節點發送一條ping命令做一次心跳檢測，來確認

當前節點是否可達。與主節點，從節點，其余Sentinel都建立起連接，實現了對每個節點的監控。這個定時任務

是節點失敗判定的重要依據。

七. Redis Sentinel部署技巧

1.Sentinel節點不應該部署在一臺物理機上。

2.部署至少三個且奇數個的Sentinel節點

3.只有一套Sentinel，還是每個主節點配置一套Sentinel的討論的建議方案是如果Sentinel節點集合監控的是同一個

業務的多個主節點集合，那麽使用方案一，否則使用方案2.

八. Redis Cluster|數據分區

Redis數據分區：RedisCluster采用虛擬槽分區，所有的鍵根據哈希函數映射到0-16383整數槽內，

計算公式：slot=CRC16(key) &16383。每一個節點負責維護一部分槽以及槽所映射的鍵值數據。

Redis虛擬槽分區的特點：

1.解耦數據和節點之間的關系，簡化了節點擴容和收縮的難度

2.節點自身維護槽的映射關系，不需要客戶端或者代理服務維護槽分區元數據

3.支持節點、槽、鍵之間的映射查詢，用於數據路由、在線伸縮等場景。

九. Redis Cluster|功能限制

1.Key批量操作支持有限。目前只支持同slot內的key執行批量操作（如mget,mset）。

2.Key事務操作支持有限。只支持多key在同一個節點上的事務操作，多個key分布在不同節點上時無法使用事務功能。

3.Key作為數據分區的最小粒度，因此不能將一個大的鍵值對象如hash，list等映射到不同節點。

4.不支持多數據庫空間，集群模式下只能使用db0空間。

5.復制結構只支持一層，從節點只能復制主節點，不支持嵌套樹狀復制結構。

十. Redis Cluster|集群伸縮

Redis集群提供了靈活的節點擴容和收縮方案，在不影響集群對外服務的情況下，可以為集群添加節點進行

擴容也可以下線部分節點進行縮容。

擴容集群的步驟：

1.準備新節點

2.加入集群

3.遷移槽和數據

縮容集群的步驟：

1.首先要確定下線節點是否有負責的槽，如果是，需要把槽遷移到其他節點，保證節點下線後真個集群槽節點映射的完整性

2.當下線節點不再負責槽或者本身是從節點時，就可以通知集群內其他節點忘記下線節點，就可以通知集群內其他節點忘記下線節點當所有的節點忘記該節點後可以正常關閉。

十一. Redis Cluster|故障發現

Redis集群自身實現了高可用。高可用首先需要解決集群部分失敗的場景：當少數節點出現故障時，可以通過

自動故障轉移保證集群可以正常對外提供服務。

故障發現的類型：

1.主觀下線：指某個節點認為另一個節點不可用，即下線狀態，這個狀態並不是最終的故障判定，只能代表一個節點的意見，可能存在誤判情況。

2.客觀下線：指標記一個節點真正的下線，集群內多個節點都認為該節點不可用，從而達成共識的結果。如果持有槽的主節點故障，需要為該節點進行故障轉移。

十二. Redis Cluster|故障恢復

故障節點變為客觀下線後，如果下線節點是持有槽的主節點，則需要在它的從節點中選出一個替換它。從而保證集群高可用。下線主節點的所有從節點承擔故障恢復的義務，當從節點通過內部定時任務發現自身復制的主節點進入客觀下線時，將會觸發故障恢復流程。

Redis高可用方案-哨兵與集群