一、Redis Cluster

Cluster介紹?

Redis 集群采用無中心的方式，為了維護集群狀態統一，節點之間需要互相交換消息。Redis采用交換消息的方式被稱為 Gossip ，基本思想是節點之間互相交換信息最終所有節點達到一致，更多關于 Gossip 可參考 https://en.wikipedia.org/wiki/Gossip_protocol 。

?

Redis 集群是一個提供在多個Redis間節點間共享數據的程序集。

?

Redis集群并不支持處理多個keys的命令,因為這需要在不同的節點間移動數據,從而達不到像Redis那樣的性能,在高負載的情況下可能會導致不可預料的錯誤.

?

Redis 集群的特點:

• 自動分割數據到不同的節點上。
• 整個集群的部分節點失敗或者不可達的情況下能夠繼續處理命令。

• 可線性擴展到上千個節點

• 可使數據自動路由到多個節點

• 實現了多個節點間的數據共享

• 可支持動態增加或刪除節點

• 可保證某些節點無法提供服務時不影響整個集群的操作

• 不保證數據的強一致性

• 支持Redis所有處理單個數據庫鍵的命令

• 不支持對多個數據庫鍵的操作，比如MSET、SUNION

• 不能使用?SELECT?命令，集群只使用默認的0號數據庫

架構細節:

(1)所有的redis節點彼此互聯(PING-PONG機制),內部使用二進制協議優化傳輸速度和帶寬.

(2)節點的fail是通過集群中超過半數的節點檢測失效時才生效.

(3)客戶端與redis節點直連,不需要中間proxy層.客戶端不需要連接集群所有節點,連接集群中任何一個可用節點即可

(4)redis-cluster把所有的物理節點映射到[0-16383]slot上,cluster 負責維護node<->slot<->value

?

redis-cluster選舉:容錯

(1)領著選舉過程是集群中所有master參與,如果半數以上master節點與master節點通信超過(cluster-node-timeout),認為當前master節點掛掉.

(2):什么時候整個集群不可用(cluster_state:fail),當集群不可用時,所有對集群的操作做都不可用，收到((error) CLUSTERDOWN The cluster is down)錯誤

? ? a:如果集群任意master掛掉,且當前master沒有slave.集群進入fail狀態,也可以理解成進群的slot映射[0-16383]不完成時進入fail狀態.

? ? b:如果進群超過半數以上master掛掉，無論是否有slave集群進入fail狀態。

Redis 集群的數據分片

?

Hash?Slot?

Redis集群沒有使用一致性hash，而是引入了哈希槽（Hash?Slot）的概念。

Redis集群一共有16384個哈希槽，每個key通過CRC16校驗后對16384取模來決定對應哪個槽。

HASH_SLOT?=?CRC16(key)?mod?16384

每個主節點都負責處理?16384?個哈希槽的其中一部分，由于Redis?集群的key被分割為?16384?個slot，?所以集群的最大節點數量也是?16384?個。推薦的最大節點數量為1000個左右。

舉個例子，比如當前集群有3個節點,那么：

• 節點 A 包含 0 到 5500號哈希槽。
• 節點 B 包含5501 到 11000 號哈希槽。
• 節點 C 包含11001 到 16384號哈希槽。

這 種結構很容易添加或者刪除節點。比如如果我想新添加個節點D，我需要從節點 A, B, C中得部分槽到D上。如果我像移除節點A,需要將A中得槽移到B和C節點上,然后將沒有任何槽的A節點從集群中移除即可。由于從一個節點將哈希槽移動到另 一個節點并不會停止服務,所以無論添加刪除或者改變某個節點的哈希槽的數量都不會造成集群不可用的狀態。

?

說明：

所有的哈希槽必須配置在集群中的某一個節點上。

節點和哈希槽之間的對應關系在搭建集群時配置，集群使用中也支持動態遷移。

?

Redis 集群的主從復制模型

為了使在部分節點失敗或者大部分節點無法通信的情況下集群仍然可用，所以集群使用了主從復制模型,每個節點都會有N-1個復制品.

在我們例子中具有A，B，C三個節點的集群,在沒有復制模型的情況下,如果節點B失敗了，那么整個集群就會以為缺少5501-11000這個范圍的槽而不可用.

然而如果在集群創建的時候（或者過一段時間）我們為每個節點添加一個從節點A1，B1，C1,那么整個集群便有三個master節點和三個slave節點組成，這樣在節點B失敗后，集群便會選舉B1為新的主節點繼續服務，整個集群便不會因為槽找不到而不可用了

不過當B和B1 都失敗后，集群是不可用的.

Redis 一致性保證

Redis 并不能保證數據的強一致性. 這意味這在實際中集群在特定的條件下可能會丟失寫操作.

第一個原因是因為集群是用了異步復制. 寫操作過程:

• 客戶端向主節點B寫入一條命令.
• 主節點B向客戶端回復命令狀態.
• 主節點將寫操作復制給他得從節點 B1, B2 和 B3.

主 節點對命令的復制工作發生在返回命令回復之后， 因為如果每次處理命令請求都需要等待復制操作完成的話， 那么主節點處理命令請求的速度將極大地降低 —— 我們必須在性能和一致性之間做出權衡。 注意：Redis 集群可能會在將來提供同步寫的方法。 Redis 集群另外一種可能會丟失命令的情況是集群出現了網絡分區， 并且一個客戶端與至少包括一個主節點在內的少數實例被孤立。

舉個例子 假設集群包含 A 、 B 、 C 、 A1 、 B1 、 C1 六個節點， 其中 A 、B 、C 為主節點， A1 、B1 、C1 為A，B，C的從節點， 還有一個客戶端 Z1 假設集群中發生網絡分區，那么集群可能會分為兩方，大部分的一方包含節點 A 、C 、A1 、B1 和 C1 ，小部分的一方則包含節點 B 和客戶端 Z1 .

Z1仍然能夠向主節點B中寫入, 如果網絡分區發生時間較短,那么集群將會繼續正常運作,如果分區的時間足夠讓大部分的一方將B1選舉為新的master，那么Z1寫入B中得數據便丟失了.

注意， 在網絡分裂出現期間， 客戶端 Z1 可以向主節點 B 發送寫命令的最大時間是有限制的， 這一時間限制稱為節點超時時間（node timeout）， 是 Redis 集群的一個重要的配置選項：

?

?

?

二、Redis Sentinel

Sentinel介紹

Sentinel 是Redis官方為集群提供的高可用解決方案。 在實際項目中可以使用sentinel去做redis自動故障轉移，減少人工介入的工作量。另外sentinel也給客戶端提供了監控消息的通知，這樣客 戶端就可根據消息類型去判斷服務器的狀態，去做對應的適配操作。

下面是Sentinel主要功能列表：

監控（Monitoring）： Redis Sentinel實時監控主服務器和從服務器運行狀態。

提醒（Notification）：當被監控的某個 Redis 服務器出現問題時， Redis Sentinel 可以向系統管理員發送通知， 也可以通過 API 向其他程序發送通知。

自 動故障轉移（Automatic failover）： 當一個主服務器不能正常工作時，Redis Sentinel 可以將一個從服務器升級為主服務器， 并對其他從服務器進行配置，讓它們使用新的主服務器。當應用程序連接到 Redis 服務器時， Redis Sentinel會告之新的主服務器地址和端口。

Redis Sentinel 是一個分布式系統， 你可以在架構中運行多個 Sentinel 進程，這些進程通過相互通訊來判斷一個主服務器是否斷線，以及是否應該執行故障轉移。

在 配置Redis Sentinel時，至少需要有1個Master和1個Slave。當Master失效后,Redis Sentinel會報出失效警告，并通過自動故障轉移將Slave提升為Master，并提供讀寫服務;當失效的Master恢復后，Redis Sentinel會自動識別，將Master自動轉換為Slave并完成數據同步。

通過Redis Sentinel可以實現Redis零手工干預并且短時間內進行M-S切換，減少業務影響時間。

拓撲結構

?

在 兩個服務器中分別都部署Redis和Redis Sentinel。當Master中的Redis出現故障時（Redis進程終止、服務器僵死、服務器斷電等），由Redis Sentinel將Master權限切換至Slave Redis中，并將只讀模式更改為可讀可寫模式。應用程序通過Redis Sentinal確定當前Master Redis位置，進行重新連接。

根據業務模式，可以制定兩種拓撲結構：單M-S結構和雙M-S結構。如果有足夠多的服務器，可以配置多M-S結構。

1、單M-S結構

單 M-S結構特點是在Master服務器中配置Master Redis（Redis-1M）和Master Sentinel（Sentinel-1M）。Slave服務器中配置Slave Redis（Redis-1S）和Slave Sentinel（Sentinel-1S）。其中 Master Redis可以提供讀寫服務，但是Slave Redis只能提供只讀服務。因此，在業務壓力比較大的情況下，可以選擇將只讀業務放在Slave Redis中進行。

?

?

2、雙M-S結構

雙 M-S結構的特點是在每臺服務器上配置一個Master Redis，同時部署一個Slave Redis。由兩個Redis Sentinel同時對4個Redis進行監控。兩個Master Redis可以同時對應用程序提供讀寫服務，即便其中一個服務器出現故障，另一個服務器也可以同時運行兩個Master Redis提供讀寫服務。缺點是兩個Master redis之間無法實現數據共享，不適合存在大量用戶數據關聯的應用使用。

?

3、優劣對比

兩個結構各有優缺點，分別適用于不同的應用場景：

單M-S結構適用于不同用戶數據存在關聯，但應用可以實現讀寫分離的業務模式。Master主要提供寫操作，Slave主要提供讀操作，充分利用硬件資源。

雙（多）M-S結構適用于用戶間不存在或者存在較少的數據關聯的業務模式，讀寫效率是單M-S的兩（多）倍，但要求故障時單臺服務器能夠承擔兩個Mater Redis的資源需求。

?

總結

以上是生活随笔為你收集整理的Redis Cluster 高可用方案的全部內容，希望文章能夠幫你解決所遇到的問題。

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