前言

Redis的主從、哨兵模式、集群模式，在前文中都已經(jīng)有了詳細的搭建流程，可謂是手把手教程，也得到了很多朋友的喜歡。由于前文偏向于應(yīng)用方面，就導(dǎo)致了理論知識的匱乏，我們可能會用了，但卻不明所以，所以今天，博主就通過接下里的幾篇博客給大家分別講解Redis哨兵機制的原理和集群模式下的原理。

導(dǎo)讀

在開始講解之前，博主把前面幾篇博客的地址放在這里供大家去翻閱：

Java開發(fā) - 讓你少走彎路的Redis的主從復(fù)制

Java開發(fā) - 讓你少走彎路的Redis主從實現(xiàn)單節(jié)點哨兵模式

Java開發(fā) - 讓你少走彎路的Redis集群搭建

在這三篇Redis內(nèi)容中，已經(jīng)從主從到哨兵再到集群給大家一步步做了詳細的應(yīng)用講解，如果你對Redis的使用還存在一定的問題的話不妨去看看，興許會有一些新的收獲。

多哨兵模式的疑問

在?Redis集群搭建這篇博客的末尾，博主有這么一段話，見下方：

?一個sentinel哨兵大家會了，但是多個sentinel哨兵怎么讓他們彼此之間也能監(jiān)聽到呢？誠如博主所說，多個哨兵和一個哨兵的使用方法是一樣的，只需要監(jiān)聽主節(jié)點，其他的，哨兵會自動完成。

不信？博主專門搭建了一個多哨兵的Redis，我們來看看。

這是我的Redis和Sentinel配置文件：

Redis架構(gòu)如下：

就是簡單的一主二從。

Sentinel的架構(gòu)如下：

我們分別啟動三個Redis和三個Sentinel：

至于配置，就和我博客里面的一摸一樣，大家可以照著自己做，這里是演示多個sentinel的工作情況。

如果你要是自己看了報文，你就會發(fā)現(xiàn)細節(jié)：

這個26380的：

這是26379的：

唯一配置變的地方還真有一個，就是在sentinel的配置文件中：

sentinel monitor mymaster 127.0.0.1 6379 2

監(jiān)聽的主節(jié)點后面的數(shù)字變了，一個sentinel的時候?qū)?，三個sentinel的時候要過半的sentinel認為主節(jié)點掛掉才能故障轉(zhuǎn)移和切換，三個，那過半就寫2了，如果你有更多sentinel，這個數(shù)字也要改變。當然，你寫1也行，但可能出現(xiàn)誤判的情況。

測試關(guān)閉主節(jié)點：

已關(guān)閉，此時看從節(jié)點：

出現(xiàn)了短暫的連接被拒絕的情況，此時我們發(fā)現(xiàn)sentinel沒有任何變化，大概也就是幾秒鐘的樣子，變化產(chǎn)生了：

此時去看其他的sentinel節(jié)點，會發(fā)現(xiàn)有明顯的選舉過程：

此時如果把sentinel6379下線掉之后，會發(fā)生什么？我們試試；

大概在幾秒后，sentinel做出了反應(yīng)，同時輸出26379離線的通知，但是Redis那邊沒有任何的反應(yīng)，這個正常，畢竟不是redis監(jiān)控哨兵，是吧？?

到這里，還需要博主繼續(xù)下去嗎？一切已經(jīng)說明了問題。?多哨兵的模式按照博主的方式放心用就行了。

到此，多sentinel使用也算是給大家做了演示，加油哦！

Redis哨兵工作原理

從上面的測試來看，當主節(jié)點發(fā)生故障掛掉之后，大概時間是18s，sentinel感知到故障，執(zhí)行自動的故障遷移，當然，這個時間是可以自己調(diào)整的。為了了解這種工作機制，我們有必要來了解下sentinel的三種定時監(jiān)控任務(wù)。

INFO指令獲得最新節(jié)點拓撲圖

每個sentinel每隔10s就會向主節(jié)點發(fā)送INFO命令，然后獲取整個Redis節(jié)點的拓撲圖，這也是為什么，當有節(jié)點退出，或有節(jié)點加入時，sentinel能極快的感知到拓撲圖變化的原因，也是我們只需要指定主節(jié)點而不需要指定從節(jié)點的原因。

此時還沒有完，sentinel通過INFO命令感知到拓撲圖后，就發(fā)現(xiàn)了主節(jié)點下的其他從節(jié)點，等到下個10s后，就會同時向主節(jié)點和從節(jié)點發(fā)送INFO命令，以達到監(jiān)聽所有redis節(jié)點的目的。

此處應(yīng)該有圖，但是我好懶，我覺得大家應(yīng)該明白了這個道理了吧？

通過發(fā)布訂閱獲得Master節(jié)點和其他Sentinel的信息

每個sentinel間隔2s會向指定頻道發(fā)送自己關(guān)于主節(jié)點是否正常的判斷，同時還包含當前sentinel節(jié)點的信息，其他sentinel通過訂閱這個頻道就可以達到信息共享的目的，此時就可以判斷master節(jié)點是不是活的，sentinel節(jié)點是不是活的。

解釋下關(guān)于訂閱頻道的理解，對于監(jiān)視同一個主節(jié)點的多個Sentinel來說，一個Sentinel發(fā)送的信息會被其他Sentinel接收到，這其他Sentinel會根據(jù)這些信息來做出對master和對應(yīng)sentinel的判斷。我們可以認為他們是通過主節(jié)點達到數(shù)據(jù)共享的。

我們暫時就理解到這里，不再做更多深層的源碼方面的理解。

但當博主打開了sentinel26379的配置文件，偶然在最末位發(fā)現(xiàn)了這幾段自動生成的配置，似乎打開了新世界的大門：

known- sentinel就是知道另一個sentinel，這都是自動完成的，其原理博主不得，但猜測是通過Master節(jié)點完成的數(shù)據(jù)的共享，上圖似乎也是一個對我們假設(shè)的印證。

PING指令?跳檢測

每個Sentinel每隔1秒會向所有節(jié)點（?Sentinel?節(jié)點、?Master?節(jié)點、?Slave?節(jié)點）發(fā)送PING指令來進??跳檢測。

選舉過程

• 在上面的案例中，當一個sentinel節(jié)點認為Master不可用時，會進行主觀下線，但并不會真的下線，而是繼續(xù)通過sentinel is-masterdown-by-addr指令來獲取其他sentinel對Master節(jié)點的判斷，如果最終判斷的值達到了我們設(shè)置的quorum值，Master節(jié)點就被判定為客觀下線；
• Leader Sentinel（每個發(fā)現(xiàn)master服務(wù)器進入下線的sentinel都可以要求其他sentinel選自己為sentinel的leader,選舉是先到先得）會從原來的Master的Slave中選出一個做為新的主節(jié)點
  • 首先過濾所有主觀下線的節(jié)點；
  • 選擇slave-priority最高的節(jié)點，有的話返回，沒有的話繼續(xù)；
  • 選擇復(fù)制偏移量offset最?的節(jié)點，有的話返回，沒有的話繼續(xù)；
  • 選擇run_id（服務(wù)器運? ID）最?的節(jié)點，
• 最終選出一個節(jié)點，Leader Sentinel節(jié)點會通過?SLAVEOF NO ONE命令，讓選擇出來的Slave變?yōu)樾碌腗aster，再通過SLAVEOF命令讓其他還活著的節(jié)點成為新的Master的Slave節(jié)點。

最后推薦一篇文章，我覺得講解通信的過程講的很詳細：一文讀懂Redis的哨兵機制 - 知乎

好東西當然是要一起分享了。

結(jié)語

寫到這里，Redis的哨兵模式基本是給大家講解清楚了，不知道你get到了多少？如果還有其他疑問，不放評論區(qū)留言和小伙伴們一起討論吧，最后，不要吝嗇你們的贊，動動小手，給博主一個大大的支持吧。文章來源地址http://www.zghlxwxcb.cn/news/detail-580606.html

到了這里，關(guān)于Java開發(fā) - 深入理解Redis哨兵機制原理的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！