Redis哨兵(Sentinel)模式

一、主從復制高可用
當我們使用主從復制出現的問題
- 手動故障轉移
- 寫能力和存儲能力受限
- 主從復制 -master 宕機故障處理
主從切換技術的方法是:當主服務器宕機后,需要手動把一臺從服務器切換為主服務器,這就需要人工干預,費事費力,還會造成一段時間內服務不可用。這不是一種推薦的方式,更多時候,我們優先考慮哨兵模式。
~哨兵模式概述
哨兵模式是一種特殊的模式,首先Redis提供了哨兵的命令,哨兵是一個獨立的進程,作為進程,它會獨立運行。其原理是哨兵通過發送命令,等待Redis服務器響應,從而監控運行的多個Redis實例。
哨兵主要有兩個作用
通過發送命令,讓Redis服務器返回監控其運行狀態,包括主服務器和從服務器。
當哨兵監測到master宕機,會自動將slave切換成master,然后通過發布訂閱模式通知其他的從服務器,修改配置文件,讓它們切換主機。
然而一個哨兵進程對Redis服務器進行監控,可能會出現問題,為此,我們可以使用多個哨兵進行監控。各個哨兵之間還會進行監控,這樣就形成了多哨兵模式。
故障切換(failover)的過程。假設主服務器宕機,哨兵1先檢測到這個結果,系統并不會馬上進行failover過程,僅僅是哨兵1主觀的認為主服務器不可用,這個現象成為主觀下線。當后面的哨兵也檢測到主服務器不可用,并且數量達到一定值時,那么哨兵之間就會進行一次投票,投票的結果由一個哨兵發起,進行failover操作。切換成功后,就會通過發布訂閱模式,讓各個哨兵把自己監控的從服務器實現切換主機,這個過程稱為客觀下線。這樣對于客戶端而言,一切都是透明的。
二、架構說明

- 多個sentinel 發現并確認master有問題。
- 選舉出一個sentinel作為領導
- 選出一個slave作為master
- 通知其余的slave成為新的master的slave
- 通知客戶端主從變化
- 等待老的master復活成新的master的slave
三、安裝配置

- 配置主從節點
- 主節點
啟動命令:redis-server redis-7000.conf
配置
port?7000
daemonize?yes
pidfile?/var/run/redis-7000.pid
logfile?"7000.log"
dir?"/opt/soft/redis/data/"
- Redis從節點
redis-server?redis-7001.conf
redis-server?redis-7002.conf
slave-1:
port?7002
daemonize?yes
pidfile?/var/run/redis-7002.pid
logfile?"7002.log"
dir?"/opt/soft/redis/data/"
slaveof?127.0.0.1?7000
slave-2:
port?7001
daemonize?yes
pidfile?/var/run/redis-7001.pid
logfile?"7001.log"
dir?"/opt/soft/redis/data/"
slaveof?127.0.0.1?7000
- 配置開啟sentinel監控主節點
- sentine 主要配置 ?編輯 sentinel.conf
port?${port}
dir?"/opt/soft/redis/data/"
logfile?"${port}.log"
//?配置監聽的主服務器,這里sentinel monitor代表監控,mymaster代表服務器的名稱,可以自定義,192.168.11.128代表監控的主服務器,6379代表端口,2代表只有兩個或兩個以上的哨兵認為主服務器不可用的時候,才會進行failover操作。
sentinel?monitor?mymaster?127.0.0.1?7000?2???
sentinel?down-after-millseseconds?mymaster?30000?//判斷主節點時間
sentinel?parallel-syncs?mymaster?1????
sentinel?failover-timeout?mymaster?180000
啟動
redis-sentinel?sentinel.conf
可以使用 ps -ef|grep redis-sentinel 命令查看進程、
四、實現原理
- 故障轉移 ? ? --- java實現
/**
?*?測試Redis哨兵模式
?*?@author?liu
?*/
public?class?TestSentinels?{
????@SuppressWarnings("resource")
????@Test
????public?void?testSentinel()?{
????????JedisPoolConfig?jedisPoolConfig?=?new?JedisPoolConfig();
????????jedisPoolConfig.setMaxTotal(10);
????????jedisPoolConfig.setMaxIdle(5);
????????jedisPoolConfig.setMinIdle(5);
????????//?哨兵信息
????????Set?sentinels?=?new?HashSet<>(Arrays.asList("127.0.0.1:26379","1127.0.0.1:26379","127.0.0.1:26379"));//?創建連接池
????????JedisSentinelPool?pool?=?new?JedisSentinelPool("mymaster",?sentinels,jedisPoolConfig,"123456");//?獲取客戶端
????????Jedis?jedis?=?pool.getResource();//?執行兩個命令
????????jedis.set("mykey",?"myvalue");
????????String?value?=?jedis.get("mykey");
????????System.out.println(value);
????}
}
如果我們把主服務器停掉,在經過一段時間的報錯后,redis集群會恢復
主觀下線和客觀下線
主觀下線:當前sentintel節點認為某個redis節點不可用。
客觀下線:所有sentinel節點認為某個redis節點不可用。
三個定時任務
每10秒每個sentinel對master 和 slave執行info
- 發現slave節點
- 確認主從關系每2秒每個sentinel通過master節點對channel交換信息(發布訂閱)
- 通過_sentinel_:hello頻道交互
- 交互對節點的“看法”和自身信息每1秒每個sentinel 對其他sentinel和redis執行ping
領導者選舉
只需要一個sentinel節點完成故障轉移
通過sentinel is - master -down -by-addr 命令都希望成為領導者
-1. 每個主觀下線都Sentitle 節點向其他Sentinel節點發送命令,要求將它設置為領導者
-2. 收到命令對Sentinel節點如果沒有同一通過其他Sentinel節點發送的命令,那么就將同一該請求,否則拒絕
-3. 如果該Sentinel節點發現直接的票數已經超過Sentinel集合半數且超過quorum,那么它將成為領導者
-4. 如果此過程由多個Sentinel節點成為領導者,那么將來等待一段時間重新進行選舉

故障轉移(Sentinel領導者節點完成)
- 1.從slave節點中選出一個 “合適點”節點作為master節點
- 2.對上面對slave節點執行slaveof no one 命令讓其成為master節點。
- 3.向剩余的slave節點發送命令,讓它們成為新的maater節點的slave節點,復制規避和parallel-syncs參數有關
- 4.更新對原來master節點配置為slave,并保持著對其 “關注”,當其恢復后命令他去復制新對master節點
選擇 “合適的” slave節點
- 1.選擇slave-priority(slave節點優先級)最高對slave節點,如果存在返回,不存在繼續
- 2.選擇復制偏移量最大的slave節點,復制最完整,存在返回,不存在繼續
- 3.選擇runId最小的slave節點
五、需要說明的問題
- 盡可能在不同物理機上和同一個網絡部署Redis sentinel的所有節點
- Redis sentinel中的sentinel節點個數應該大于等于3且最好是奇數。(節點數多可以保證高可用)
- Redis sentinel中的數據節點和普通數據節點沒有區別。每個sentinel節點在本質上還是一個Redis實例,只不過和Redis數據節點不同的是,其主要作用是監控Redis數據節點
- 客戶端初始化時連接的是sentinel節點集合,不再是具體的Redis節點,但sentinel只是配置中心不是代理。
個人博客:http://blog.yanxiaolong.cn/