天天看點

Redis Cluster 高可用方案

redis 叢集是一個提供在多個redis間節點間共享資料的程式集。

redis叢集并不支援處理多個keys的指令,因為這需要在不同的節點間移動資料,進而達不到像redis那樣的性能,在高負載的情況下可能會導緻不可預料的錯誤.

redis 叢集的特點:

自動分割資料到不同的節點上。

整個叢集的部分節點失敗或者不可達的情況下能夠繼續處理指令。

可線性擴充到上千個節點

可使資料自動路由到多個節點

實作了多個節點間的資料共享

可支援動态增加或删除節點

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

不保證資料的強一緻性

支援redis所有處理單個資料庫鍵的指令

不支援對多個資料庫鍵的操作,比如mset、sunion

不能使用 select 指令,叢集隻使用預設的0号資料庫

Redis Cluster 高可用方案

架構細節:

(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狀态。

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節點從叢集中移除即可。由于從一個節點将哈希槽移動到另

一個節點并不會停止服務,是以無論添加删除或者改變某個節點的哈希槽的數量都不會造成叢集不可用的狀态。

說明:

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

節點和哈希槽之間的對應關系在搭建叢集時配置,叢集使用中也支援動态遷移。

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

在我們例子中具有a,b,c三個節點的叢集,在沒有複制模型的情況下,如果節點b失敗了,那麼整個叢集就會以為缺少5501-11000這個範圍的槽而不可用.

然而如果在叢集建立的時候(或者過一段時間)我們為每個節點添加一個從節點a1,b1,c1,那麼整個叢集便有三個master節點和三個slave節點組成,這樣在節點b失敗後,叢集便會選舉b1為新的主節點繼續服務,整個叢集便不會因為槽找不到而不可用了

不過當b和b1 都失敗後,叢集是不可用的.

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 叢集的一個重要的配置選項:

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結構。

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中進行。

Redis Cluster 高可用方案

m-s結構的特點是在每台伺服器上配置一個master redis,同時部署一個slave redis。由兩個redis

sentinel同時對4個redis進行監控。兩個master

redis可以同時對應用程式提供讀寫服務,即便其中一個伺服器出現故障,另一個伺服器也可以同時運作兩個master

redis提供讀寫服務。缺點是兩個master redis之間無法實作資料共享,不适合存在大量使用者資料關聯的應用使用。

Redis Cluster 高可用方案

<a href="http://photo.blog.sina.com.cn/showpic.html#blogid=75ad98f30101fwqj&amp;url=http://album.sina.com.cn/pic/0029c0wjgy6eewx6tvyba"></a>

兩個結構各有優缺點,分别适用于不同的應用場景:

單m-s結構适用于不同使用者資料存在關聯,但應用可以實作讀寫分離的業務模式。master主要提供寫操作,slave主要提供讀操作,充分利用硬體資源。

雙(多)m-s結構适用于使用者間不存在或者存在較少的資料關聯的業務模式,讀寫效率是單m-s的兩(多)倍,但要求故障時單台伺服器能夠承擔兩個mater redis的資源需求。