2. 程式人生 > >Redis高可用簡介

Redis高可用簡介

阿新 • • 發佈：2018-12-23

常見Redis部署方式有以下幾種：

  1. 單節點
  2. 主從
  3. Sentinel
  4. Cluster
  5. 代理(Twemproxy等)

下面只分析Sentinel、Cluster、代理的高可用

一、Sentinel

在這裡插入圖片描述

定時任務

  1. 每個 Sentinel 以每秒鐘一次的頻率向它所知的主伺服器、從伺服器以及其他 Sentinel 例項傳送一個 PING 命令。 判斷是否客觀下線。
    在這裡插入圖片描述
  2. 每個Sentinel 會以每 10 秒一次的頻率向它已知的所有主伺服器和從伺服器傳送 INFO 命令。用來發現slave節點、確認主從關係。
    在這裡插入圖片描述
  3. 每個 Sentinel 會以每兩秒一次
    的頻率， 通過釋出與訂閱功能， 向被它監視的所有主伺服器和從伺服器的 sentinel:hello 頻道傳送一條資訊， 資訊中包含了 Sentinel 的 IP 地址、埠號和執行 ID （runid）。Sentinel 之間也通過該頻道互相交換資訊。
    在這裡插入圖片描述

主觀下線和客觀下線

Redis 的 Sentinel 中關於下線（down）有兩個不同的概念：

  • 主觀下線指的是單個 Sentinel 例項對伺服器做出的下線判斷。
  • 客觀下線指的是多個 Sentinel 例項在對同一個伺服器做出SDOWN 判斷， 並且通過 SENTINEL is-master-down-by-addr 命令互相交流之後， 得出的伺服器下線判斷。最後當達成這一共識的sentinel個數達到前面說的quorum設定的這個值時，就會對該master節點下線進行故障轉移。quorum的值一般設定為sentinel個數的二分之一加1，例如3個sentinel就設定2

故障轉移

領導者選舉
選舉出一個sentinel節點去完成故障轉移

  1. 每個做主觀下線的sentinel節點向其他sentinel節點發送上面那條命令，要求將它設定為領導者。
  2. 收到命令的sentinel節點如果還沒有同意過其他的sentinel傳送的命令（還未投過票），那麼就會同意，否則拒絕。
  3. 如果該sentinel節點發現自己的票數已經過半且達到了quorum的值，就會成為領導者
  4. 如果這個過程出現多個sentinel成為領導者，則會等待一段時間重新選舉。

master轉移

  1. 選擇slave-priority（slave節點優先順序配置）最高的slave節點，（預設都是一樣的）例如：如果我們有兩臺slave在兩臺機器上，一臺配置較高，我們希望當master掛掉優先選配置高的，就可以配置該值為slave中最高的。如果存在最高則返回，不存在繼續
  2. 選擇複製偏移量最大的節點（複製得最完整，與master節點的資料一致性更高），如果存在則返回，不存在繼續
  3. 如果以上兩個條件都不滿足，選runId最小的（啟動最早的）。

轉移完成之後
sentinel通知客戶端變更節點資訊，客戶端連線新master。如果故障master重新上線，則成為slave節點。

二、Cluster

Redis-Cluster採用無中心結構，每個節點儲存資料和整個叢集狀態，每個節點都和其他所有節點連線，節點間使用 gossip 協議來傳播叢集的資訊。其redis-cluster架構圖如下：
在這裡插入圖片描述

雜湊槽演算法

HASH_SLOT = CRC16(key) mod 16384

鍵空間被分割為 16384 槽（slot），叢集的最大節點數量是 16384 個（然而建議最大節點數量設定在1000這個數量級上）。所有的主節點都負責 16384 個雜湊槽中的一部分。
假設有三個節點，則每個節點槽區間為：

節點A覆蓋0－5460;
節點B覆蓋5461－10922;
節點C覆蓋10923－16383.

gossip 協議

gossip 協議廣播，叢集節點通過PING/PONG訊息實現節點通訊，傳播節點槽資訊。
每個節點都儲存其他節點的資訊：

  • 節點的 IP 地址和 TCP 埠號。
  • 各種標識。
  • 節點使用的雜湊槽。
  • 最近一次用叢集連線傳送 ping 包的時間。
  • 最近一次在回覆中收到一個 pong 包的時間。
  • 最近一次標識節點失效的時間。
  • 該節點的從節點個數。
  • 如果該節點是從節點，會有主節點ID資訊。

Redis Cluster主從模式

redis cluster 為了保證資料的高可用性，加入了主從模式，一個主節點對應一個或多個從節點，主節點提供資料存取，從節點則是從主節點拉取資料備份，當這個主節點掛掉後，就會有這個從節點選取一個來充當主節點，從而保證叢集不會掛掉。
其三主三從架構如下所示：
在這裡插入圖片描述
叢集部署
搭建叢集工作分為三步：

  1. 準備節點
  2. 節點握手 (MEET訊息)
  3. 分配槽(addslots)

手動MEET、addslots部署參考：https://blog.csdn.net/men_wen/article/details/72871618
Redis官方redis-trib.rb工具部署參考：https://www.cnblogs.com/wuxl360/p/5920330.html

叢集擴容與收縮
參考：https://blog.csdn.net/men_wen/article/details/72896682
增加或減少主節點時，叢集會將遷移部分槽。其餘主節點更新節點使用的雜湊槽情況。

MOVED 重定向
客戶端連線叢集中某個主節點，如果剛好這個節點就是對應這個雜湊槽，那麼這個查詢就直接被節點處理掉。否則這個節點會檢視它內部的 雜湊槽 -> 節點ID 對映，然後給客戶端返回一個 MOVED 錯誤。
ASK 重定向
ASK與MOVED類似，只不過ASK重定向發生在虛擬槽的遷移過程中。

故障檢測

Redis的gossip協議還可以通過PING/PONG訊息實現傳播主從狀態、節點故障資訊等。因此故障檢測也是就是通過訊息傳播機制實現的。
PFAIL 標識:
當一個節點在超過 NODE_TIMEOUT 時間後仍無法訪問某個節點，那麼它會用 PFAIL 來標識這個不可達的節點。無論節點型別是什麼，主節點和從節點都能標識其他的節點為 PFAIL。
FAIL 標識:
當下面的條件滿足的時候，會使用這個機制來讓 PFAIL 狀態升級為 FAIL 狀態：

  • 某個節點，我們稱為節點 A，標記另一個節點 B 為 PFAIL。
  • 節點 A 通過 gossip 欄位收集到叢集中大部分主節點標識的節點 B 的狀態資訊。
  • 如果叢集中過半數的主節點都認為節點 B 標記為 PFAIL 狀態，或者在 NODE_TIMEOUT * FAIL_REPORT_VALIDITY_MULT 這個時間內是處於 PFAIL 狀態。

如果以上所有條件都滿足了，那麼節點 A 會：

  • 標記節點 B 為 FAIL。
  • 向所有可達節點發送一個FAIL 訊息。

FAIL 訊息會強制每個接收到這訊息的節點把節點 B 標記為 FAIL 狀態。

故障轉移

當一個節點從節點發現自己正在複製的主節點進入了已下線狀態時，從節點將開始對下線主節點進行故障轉移，以下是故障轉移的執行步驟：

  1. 複製下線主節點的所有從節點裡面，會有一個從節點被選中（選舉過程下文會給出介紹）。
  2. 被選中的從節點會執行SLAVEOF no one命令，成為新的主節點。
  3. 新的主節點會撤銷所有對已下線主節點的槽指派，並將這些槽全部指派給自己。
  4. 新的主節點向叢集廣播一條PONG訊息，這條PONG訊息可以讓叢集中的其他節點立即知道這個節點已經由從節點變成了主節點，並且這個主節點已經接管了原本由已下線節點負責處理的槽。
  5. 新的主節點開始接收和自己負責處理的槽有關的命令請求，故障轉移完成。

紀元(epoch)：

  • 配置紀元(config epoch)：
    configEpoch是類似於一個版本號的東西，是關於cluster slot的一個版本號。一般來說，每一個master節點的configEpoch都是不同的（假如存在相同的configEpoch，會有衝突處理演算法來保證每個節點的configEpoch不同），並且每一個節點的configEpoch不會輕易發生改變（節點改變的情況見下面）。由於configEpoch是單調遞增的，因此當某一個節點的configEpoch改變之後，其它節點就會更新對該節點所聲稱擁有的slots的認識。

  • 當前紀元(current epoch)：
    configEpoch只是關於slots分佈的一個版本號，而currentEpoch才是真正的邏輯時鐘。通過gossip協議，叢集中的currentEpoch總是一致的（當然，特殊情況除外，如網路分割槽發生等）。currentEpoch越高，代表節點的配置或者操作越新。

config epoch的變化：

  1. 在叢集初始化的時候，通過讀取配置檔案nodes.conf中的configEpoch值，對每一個節點的configEpoch進行賦值
  2. 叢集重置(resetCluster)時，configEpoch被置為0
  3. 當一個槽遷移到某一個節點之後，尤其是叢集發生resharding的時候；當發生故障轉移(failover force)時，節點的configEpoch會被置為currentEpoch + 1
  4. 若兩個節點的configEpoch相同，並且當前節點的nodename更大，則當前節點的configEpoch=currentEpoch+1（configEpoch發生衝突時的處理）
  5. 當master發生fail的之後，slave獲得大多數master的投票時，設定slave的configEpoch為failover_auth_epoch
  6. cluster set-config-epoch命令強制設定configEpoch
  7. 當接受到其它節點發來的gossip訊息的時候，設定configEpoch為訊息中得configEpoch

選舉過程
從節點通過廣播一個 FAILOVER_AUTH_REQUEST 資料包給叢集裡的每個主節點來請求選票。然後從節點最大等待NODE_TIMEOUT*2的時間來回復（但總是至少2秒）。
一旦一個主節點給這個從節點投票，會回覆一個 FAILOVER_AUTH_ACK，並且在 NODE_TIMEOUT * 2 這段時間內不能再給同個主節點的其他從節點投票。這不是保證安全性所必需的，但對於防止多個從節點在大約同一時間被選中（即使使用不同的configEpoch）非常有用，這通常是不需要的。
從節點會忽視所有帶有的時期（epoch）引數比 currentEpoch 小的迴應（ACKs），這樣能避免把之前的投票的算為當前的合理投票。
一旦從節點接收到大於等於N/2+1個主節點的ACK，它就贏得了選舉。否則，如果在兩次NODE_TIMEOUT期間未達到多數（但總是至少2秒），則選舉將中止，並且在NODE_TIMEOUT * 4之後將再次嘗試選舉（並且始終至少4秒）。

三、Twemproxy

待補充

《Redis設計與實現》
https://redis.io/topics/sentinel
https://redis.io/topics/cluster-tutorial
https://redis.io/topics/cluster-spec
https://my.oschina.net/u/3371837/blog/1790026
https://blog.csdn.net/fengshizty/article/details/51368004/
https://blog.csdn.net/men_wen/article/category/6769467/1
https://blog.csdn.net/qq1137623160/article/details/79184686
https://www.cnblogs.com/wuxl360/p/5920330.html
https://www.jianshu.com/p/92183354183e

相關推薦

Redis高可用簡介

常見Redis部署方式有以下幾種： 單節點 主從 Sentinel Cluster 代理(Twemproxy等) 下面只分析Sentinel、Cluster、代理的高可用 一、Sentinel 定時任務 每個 Senti

搭建一個redis高可用系統

/var/ 文件 orien class star lov 信息 查詢 火墻 一、單個實例 當系統中只有一臺redis運行時，一旦該redis掛了，會導致整個系統無法運行。 單個實例 二、備份 由於單臺redis出現單點故障，就會導致整個系統不可用，所以想到的辦

Sentinel 哨兵-實現Redis高可用

客戶端連接 信息 客戶 redis 分布 nds 的確 mic sof 概述Redis哨兵為Redis提供了高可用性。實際上這意味著你可以使用哨兵模式創建一個可以不用人為幹預而應對各種故障的Redis部署。哨兵模式還提供了其他的附加功能，如監控，通知，為客戶端提供配置。下面

Redis 高可用部署

Redis 高可用 Redis 高可用原理：Redis使用sentinel機制來實現高可用，sentinel是另外一個集群，主要是用來監控所有的Redis服務器，所以主節點和從節點，監控方式仍然使用的是ping指令，sentinel每隔1秒向master發送【ping】，如果在一段時間內沒有收到【pong】或

實現redis高可用主從之sentinel

redis sentinel redis主從 redis高可用 sentinel作用 監控（Monitoring）： Sentinel 會不斷地檢查你的主服務器和從服務器是否運作正常。 提醒（Notification）： 當被監控的某個 Redis 服務器出現問題時， Sentinel 可以

生產環境實踐：redis高可用架設

rediskeepalived 經過測試，當主redis停掉的時候，可以5秒鐘內切換到從redis，反之切換到主，也是一樣的時間。 在A服務器(192.168.16.29),B服務器(192.168.16.2)上均安裝redis,keepalived。 A作為默認的master,B作為sla

Redis高可用方案哨兵機制------ 配置文件sentinel.conf詳解

有一個 發生 sim 超時時間 style 通信 配置文件 針對性 mas redis的哨兵機制是官方推薦的一種高可用（HA）方案，我們在使用Redis的主從結構時，如果主節點掛掉，這時是不能自動進行主備切換和通知客戶端主節點下線的。Redis-Sentinel機制主要用三

【獨家】終生受用的Redis高可用技術解決方案大全

帶寬 技術分享 學習 控制 單個 即使 效應 pan 元數據 最近很多朋友向我咨詢關於高可用的方案的優缺點以及如何選擇合適的方案線上使用，剛好最近在給宜人貸，光大銀行做企業內訓的時候也詳細講過，這裏我再整理發出來，供大家參考，如有不妥之處，歡迎批評指正，也歡迎推薦更好的技術

Redis 高可用 基於Sentinel + keepalived 實現

mas oba 保持 pan 分享 是否 因此 遇到 req 1 概述redis作為緩存工具，如果僅僅單機，一旦掛掉，將對業務造成嚴重的影響，因此建議生產環境上部署redis高可用環境，本文將基於Sentinel + keepalived 實現redis的高可用。本文主要

Redis高可用集群

映射 alt enabled info tcp replicas 重要 java connected Redis 高可用集群 Redis 的集群主從模型是一種高可用的集群架構。本章主要內容有：高可用集群的搭建，Jedis連接集群，新增集群節點，刪除集群節點，其他配置補充說明

Redis高可用復制集群實現

priority emc 第一條 top 主服務器 filename byte 並行復制 加載 redis簡單介紹 Redis 是完全開源免費的，遵守BSD協議，是一個高性能的key-value數據庫。Redis 與其他 key - value 緩存產品有以下三個特點：

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

可用 mar slot 解決 ali 發現 -a 物理 架構 Redis高可用方案 一.名詞解釋 二.主從復制 Redis主從復制模式可以將主節點的數據同步給從節點，從而保障當主節點不可達的情況下，從節點可以作為 後備頂上來，並且可以保障數據盡

Redis高可用技術解決方案總結

一、常見使用方式 Redis的幾種常見使用方式包括： Redis單副本； Redis多副本（主從）； Redis Sentinel（哨兵）； Redis Cluster； Redis自研。 二、各種使用方式的優缺點 1、Redis單副本 Redis單副本

如何構建 Redis 高可用架構？

1 、題記 Redis 是一個開源的使用 ANSI C 語言編寫、支援網路、可基於記憶體亦可持久化的日誌型、Key-Value 資料庫，並提供多種語言的 API。 如今，網際網路業務的資料正以更快的速度在增長，資料型別越來越豐富，這對資料處理的速度和能力提出了更高要求。Redis 是一種開源

CentOS 安裝 Redis (高可用)

原文：https://www.sunjianhua.cn/archives/centos-redis.html   下載地址: http://download.redis.io/releases/ 官方文件: https://redis.io/documentation

Redis 高可用特性之 “持久化” 詳解

轉載自  Redis 高可用特性之 “持久化” 詳解 在之前的文章中，介紹了《Redis的記憶體模型》，從這篇文章開始，將依次介紹 Redis 高可用相關的知識——持久化、複製(及讀寫分離)、哨兵、以及叢集。 本文將先說明上述幾種技術分別解決了 Redis 高可用的什麼問

Redis: 2、Redis高可用原理，搭建與驗證

Redis高可用原理，搭建與驗證   一、redis-ha原理 1 原理 redis高可用採用的是哨兵(sentinel)，多個redis-slave配備了多個哨兵程序,哨兵監控redis-master，一旦出現故障，將一臺slave提升為master。客戶端通過連線哨

Redis高可用架構—Keepalive+VIP

master ace tin 圖片 not per 經典 ron ast 最近整理一下Redis高可用架構的文檔，也準備分享出來，雖然這些架構也不是很復雜。Redis的高可用方案目前主要嘗試過5種方式，其中2種方式已經在線上使用。 1）Redis Master-Slave

（六）java與redis高可用，java連線哨兵sentinel原理

先來看下java連線redis主從結構圖： redis主從 需要在java中指定讀和寫redis源，而且是固定的，當主節點宕機之後，整個redis將不能使用，有明顯的單點問題。 使用sentinel哨兵之後為： Senti

（五）redis高可用，哨兵模式環境搭建

redis sentinel是redis高可用的實現方案，在實際生產環境中，對提高整個系統的高可用性是非常有幫助的，當主節點發生故障時，redis sentinel能自動完成故障發現和故障轉移，並通知應用方，從而實現高可用。 當主節點宕機後，sentinel在從節點