Redis的哨兵(sentinel) 系統(tǒng)用于管理多個 Redis 服務(wù)器,該系統(tǒng)執(zhí)行以下三個任務(wù):
· 監(jiān)控(Monitoring): 哨兵(sentinel) 會不斷地檢查你的Master和Slave是否運作正常。
· 提醒(Notification):當(dāng)被監(jiān)控的某個 Redis出現(xiàn)問題時, 哨兵(sentinel) 可以通過 API 向管理員或者其他應(yīng)用程序發(fā)送通知。
· 自動故障遷移(Automatic failover):當(dāng)一個Master不能正常工作時，哨兵(sentinel) 會開始一次自動故障遷移操作,它會將失效Master的其中一個Slave升級為新的Master, 并讓失效Master的其他Slave改為復(fù)制新的Master; 當(dāng)客戶端試圖連接失效的Master時,集群也會向客戶端返回新Master的地址,使得集群可以使用Master代替失效Master。
????哨兵(sentinel) 是一個分布式系統(tǒng),你可以在一個架構(gòu)中運行多個哨兵(sentinel) 進程,這些進程使用流言協(xié)議(gossipprotocols)來接收關(guān)于Master是否下線的信息,并使用投票協(xié)議(agreement protocols)來決定是否執(zhí)行自動故障遷移,以及選擇哪個Slave作為新的Master.
????每個哨兵(sentinel) 會向其它哨兵(sentinel)、master、slave定時發(fā)送消息,以確認對方是否”活”著,如果發(fā)現(xiàn)對方在指定時間(可配置)內(nèi)未回應(yīng),則暫時認為對方已掛(所謂的”主觀認為宕機” Subjective Down,簡稱sdown).
若“哨兵群”中的多數(shù)sentinel,都報告某一master沒響應(yīng),系統(tǒng)才認為該master"徹底死亡"(即:客觀上的真正down機,Objective Down,簡稱odown),通過一定的vote算法,從剩下的slave節(jié)點中,選一臺提升為master,然后自動修改相關(guān)配置.
????雖然哨兵(sentinel) 釋出為一個單獨的可執(zhí)行文件 redis-sentinel ,但實際上它只是一個運行在特殊模式下的 Redis 服務(wù)器，你可以在啟動一個普通 Redis 服務(wù)器時通過給定 --sentinel 選項來啟動哨兵(sentinel).哨兵(sentinel) 的一些設(shè)計思路和zookeeper非常類似單個哨兵(sentinel)。
哨兵模式修改配置
在redis 安裝文件中找到 sentinel.conf 配置文件
修改監(jiān)聽redis 的IP和端口號以及選舉次數(shù)，以及密碼
主節(jié)點 名稱 IP 端口號 選舉次數(shù)
修改心跳檢測 1000毫秒
因為我的redis服務(wù)器很少一主一從 所以最多合格節(jié)點數(shù)只能配置成一
sentinel parallel-syncs mymaster 數(shù)值 --- 最多多少合格節(jié)點
啟動哨兵模式
/usr/local/redis/etc/注意： 這個路徑要根據(jù)你的sentinel所在的路徑寫。
./redis-server /usr/local/redis/etc/sentinel.conf --sentinel &
啟動結(jié)果如下
下面再來確定一下從redis 的leader
ok ，現(xiàn)在讓主redis 宕機
因為現(xiàn)在從redis 就一個 192.168.2.108
此時查看從redis 的信息 這是從redis 的角色已經(jīng)變成master了
此時插入數(shù)據(jù)，已經(jīng)可以做寫入了
至此redis 的哨兵機制已經(jīng)驗證成功了。
。。。。。
那么如果現(xiàn)在把原先那個主的啟動又會怎樣呢？感興趣的小伙伴可以繼續(xù)向下看實驗。
原來主的角色已經(jīng)變成從的了。已經(jīng)沒有寫的權(quán)限了。
好了，針對本次實驗，總結(jié)一下整個過程。
本次實驗
1、最開始 主的redis 服務(wù)器 命名為A 從的redis服務(wù)器命名為B。
2、為 B 配上redis的哨兵監(jiān)聽。
3、讓A宕機，此時就剩一臺B 。根據(jù)哨兵機制的投票選舉算法只能選擇B 此時B 就成了主redis。
4、當(dāng)原先A重新啟動，此時A 已經(jīng)是從redis了。
