Redis全稱REmote DIctionary Server，是一個開源的使用ANSI C語言編寫、遵守BSD協議、支持網絡、可基于內存亦可持久化的日志型、Key-Value數據庫，并提供多種語言的API。它通常被稱為數據結構服務器，因為值(value)可以是字符串(String), 哈希(Hash), 列表(list), 集合(sets) 和有序集合(sorted sets)等類型。

Redis經常會被用于數據的緩存，session共享等場景下，Redis的本身的高可用就特別值得關注，我們來針對常用的兩種高可用架構進行說明。

◆◆Redis Sentinel(哨兵)◆◆

Redis Sentinel集群是由若干Sentinel節點組成的分布式集群，可以實現故障發現、故障自動轉移、配置中心和客戶端通知。Redis Sentinel的節點數量要滿足2n+1(n>=1)的奇數個。

哨兵模式其實是有2個集群在同時工作，一個是sentinel的集群，一個是數據節點的集群。典型的一個高可用架構如下圖所示：

Sentinel架構的主要作用是解決主從模式下主節點的故障轉移工作的。這里如果主節點因為故障下線，那么某個sentinel節點發送檢測消息給主節點時，如果在指定時間內收不到回復，那么該sentinel就會主觀的判斷該主節點已經下線，那么其會發送消息給其余的sentinel節點，詢問其是否“認為”該主節點已下線，其余的sentinel收到消息后也會發送檢測消息給主節點，如果其認為該主節點已經下線，那么其會回復向其詢問的sentinel節點，告知其也認為主節點已經下線，當該sentinel節點最先收到超過指定數目(配置文件中配置的數目和當前sentinel節點集合數的一半，這里兩個數目的較大值)的sentinel節點回復說當前主節點已下線，那么其就會對主節點進行故障轉移工作。轉移完成后，sentinel也會通知客戶端進行節點的轉移。

◆◆客戶端實現◆◆

客戶端從過去直接連接Redis ，變成先連接一個Sentinel實例使用 SENTINEL get-master-addr-by-name master-name 獲取Redis地址信息。

連接返回的Redis地址信息，通過ROLE命令查詢是否是Master。如果是，連接進入正常的服務環節。否則應該斷開重新查詢。

(可選)客戶端可以通過SENTINEL sentinels 來更新自己的Sentinel實例列表。當Sentinel發起failover后，切換了新的Master，Sentinel會發送 CLIENT KILL TYPE normal命令給客戶端，客戶端需要主動斷開對老的Master的鏈接，然后重新查詢新的Master地址，再重復走上面的流程。這樣的方式仍然相對不夠實時，可以通過Sentinel提供的Pub/Sub來更快地監聽到failover事件，加快重連。

◆◆生產環境推薦◆◆

對于一個最小集群，Redis應該是一個Master帶上兩個Slave，并且開啟下列選項：

min-slaves-to-write 1

min-slaves-max-lag 10

這樣能保證寫入Master的同時至少寫入一個Slave，如果出現網絡分區阻隔并發生failover的時候，可以保證寫入的數據最終一致而不是丟失，寫入老的Master會直接失敗。

Slave可以適當設置優先級，除了0之外(0表示永遠不提升為Master)，越小的優先級，越有可能被提示為Master。如果Slave分布在多個機房，可以考慮將和Master同一個機房的Slave的優先級設置的更低以提升他被選為新的Master的可能性。

考慮到可用性和選舉的需要，Sentinel進程至少為3個，推薦為5個。如果有網絡分區，應當適當分布(比如2個在A機房， 2個在B機房，一個在C機房)等。

◆◆Redis Cluster(集群)◆◆

Sentinel模式雖然解決了高可用的問題，但是單機的容量還是受到了限制，無法實現redis的分布式集群，限制了整個集群的容量和并發性能。

Redis Cluster集群節點最小配置6個節點以上(3主3從)，其中主節點提供讀寫操作，從節點作為備用節點，不提供請求，只作為故障轉移使用。

Cluster模式有眾多的優點：

? 無中心架構；

? 數據按照slot存儲分布在多個節點，節點間數據共享，可動態調整數據分布；

? 可擴展性：可線性擴展到1000多個節點，節點可動態添加或刪除；

? 高可用性：部分節點不可用時，集群仍可用。通過增加Slave做standby數據副本，能夠實現故障自動failover，節點之間通過gossip協議交換狀態信息，用投票機制完成Slave到Master的角色提升；

? 降低運維成本，提高系統的擴展性和可用性。

限制條件

看起來很美好，cluster集群模式還是受到了一些使用上的限制：

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

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

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

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

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

故障切換過程

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

Sentinel模式提供了高可用的功能，由于redis本身的性能優異，很多企業內部的系統用這種模式足以應對。如果有些2C的應用，則推薦采用redis的cluster模式。

總結

以上是生活随笔為你收集整理的redis集群 + 哨兵 + zookeeper_技术干货 | Redis的哨兵和集群的全部內容，希望文章能夠幫你解決所遇到的問題。

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