Redis的集群方案大致有三種：1）redis cluster集群方案；2）master/slave主從方案碘橘；3）哨兵模式來進行主從替換以及故障恢復(fù)互订。
一、sentinel哨兵模式介紹
Sentinel(哨兵)是用于監(jiān)控redis集群中Master狀態(tài)的工具蛹屿，是Redis 的高可用性解決方案屁奏，sentinel哨兵模式已經(jīng)被集成在redis2.4之后的版本中。sentinel是redis高可用的解決方案错负，sentinel系統(tǒng)可以監(jiān)視一個或者多個redis master服務(wù)坟瓢，以及這些master服務(wù)的所有從服務(wù)；當某個master服務(wù)下線時犹撒，自動將該master下的某個從服務(wù)升級為master服務(wù)替代已下線的master服務(wù)繼續(xù)處理請求折联。
sentinel可以讓redis實現(xiàn)主從復(fù)制，當一個集群中的master失效之后识颊，sentinel可以選舉出一個新的master用于自動接替master的工作诚镰，集群中的其他redis服務(wù)器自動指向新的master同步數(shù)據(jù)。一般建議sentinel采取奇數(shù)臺祥款，防止某一臺sentinel無法連接到master導(dǎo)致誤切換清笨。其結(jié)構(gòu)如下:
Redis-Sentinel是Redis官方推薦的高可用性(HA)解決方案，當用Redis做Master-slave的高可用方案時刃跛，假如master宕機了抠艾，Redis本身(包括它的很多客戶端)都沒有實現(xiàn)自動進行主備切換，而Redis-sentinel本身也是一個獨立運行的進程桨昙，它能監(jiān)控多個master-slave集群检号，發(fā)現(xiàn)master宕機后能進行自動切換。Sentinel由一個或多個Sentinel 實例 組成的Sentinel 系統(tǒng)可以監(jiān)視任意多個主服務(wù)器蛙酪，以及這些主服務(wù)器屬下的所有從服務(wù)器齐苛，并在被監(jiān)視的主服務(wù)器進入下線狀態(tài)時，自動將下線主服務(wù)器屬下的某個從服務(wù)器升級為新的主服務(wù)器桂塞。
例如下圖所示：
在Server1 掉線后：
升級Server2 為新的主服務(wù)器：
Sentinel版本
Sentinel當前最新的穩(wěn)定版本稱為Sentinel 2(與之前的Sentinel 1區(qū)分開來）凹蜂。隨著redis2.8的安裝包一起發(fā)行。安裝完Redis2.8后，可以在redis2.8/src/里面找到Redis-sentinel的啟動程序玛痊。
強烈建議：如果你使用的是redis2.6(sentinel版本為sentinel 1)泥彤，你最好應(yīng)該使用redis2.8版本的sentinel 2，因為sentinel 1有很多的Bug卿啡，已經(jīng)被官方棄用，所以強烈建議使用redis2.8以及sentinel 2菱父。
Sentinel狀態(tài)持久化
snetinel的狀態(tài)會被持久化地寫入sentinel的配置文件中颈娜。每次當收到一個新的配置時，或者新創(chuàng)建一個配置時浙宜，配置會被持久化到硬盤中官辽，并帶上配置的版本戳。這意味著粟瞬，可以安全的停止和重啟sentinel進程同仆。
Sentinel作用：
1）Master狀態(tài)檢測
2）如果Master異常，則會進行Master-Slave切換裙品，將其中一個Slave作為Master俗批，將之前的Master作為Slave。
3）Master-Slave切換后市怎，master_redis.conf岁忘、slave_redis.conf和sentinel.conf的內(nèi)容都會發(fā)生改變，即master_redis.conf中會多一行slaveof的配置区匠，sentinel.conf的監(jiān)控目標會隨之調(diào)換干像。
Sentinel工作方式（每個Sentinel實例都執(zhí)行的定時任務(wù)）
1）每個Sentinel以每秒鐘一次的頻率向它所知的Master，Slave以及其他 Sentinel 實例發(fā)送一個PING命令驰弄。
2）如果一個實例（instance）距離最后一次有效回復(fù)PING命令的時間超過 own-after-milliseconds 選項所指定的值麻汰，則這個實例會被Sentinel標記為主觀下線。
3）如果一個Master被標記為主觀下線戚篙，則正在監(jiān)視這個Master的所有 Sentinel 要以每秒一次的頻率確認Master的確進入了主觀下線狀態(tài)五鲫。
4）當有足夠數(shù)量的Sentinel（大于等于配置文件指定的值）在指定的時間范圍內(nèi)確認Master的確進入了主觀下線狀態(tài)，則Master會被標記為客觀下線已球。
5）在一般情況下臣镣，每個Sentinel 會以每10秒一次的頻率向它已知的所有Master，Slave發(fā)送 INFO 命令智亮。
6）當Master被Sentinel標記為客觀下線時忆某，Sentinel 向下線的 Master 的所有Slave發(fā)送 INFO命令的頻率會從10秒一次改為每秒一次。
7）若沒有足夠數(shù)量的Sentinel同意Master已經(jīng)下線阔蛉，Master的客觀下線狀態(tài)就會被移除弃舒。 若 Master重新向Sentinel 的PING命令返回有效回復(fù)，Master的主觀下線狀態(tài)就會被移除。
三個定時任務(wù)
sentinel在內(nèi)部有3個定時任務(wù)
1）每10秒每個sentinel會對master和slave執(zhí)行info命令聋呢，這個任務(wù)達到兩個目的：
a）發(fā)現(xiàn)slave節(jié)點
b）確認主從關(guān)系
2）每2秒每個sentinel通過master節(jié)點的channel交換信息（pub/sub）苗踪。master節(jié)點上有一個發(fā)布訂閱的頻道(sentinel:hello)。sentinel節(jié)點通過sentinel:hello頻道進行信息交換(對節(jié)點的"看法"和自身的信息)削锰，達成共識通铲。
3）每1秒每個sentinel對其他sentinel和redis節(jié)點執(zhí)行ping操作（相互監(jiān)控），這個其實是一個心跳檢測器贩，是失敗判定的依據(jù)颅夺。
主觀下線
所謂主觀下線（Subjectively Down， 簡稱 SDOWN）指的是單個Sentinel實例對服務(wù)器做出的下線判斷蛹稍，即單個sentinel認為某個服務(wù)下線（有可能是接收不到訂閱吧黄，之間的網(wǎng)絡(luò)不通等等原因）。
主觀下線就是說如果服務(wù)器在down-after-milliseconds給定的毫秒數(shù)之內(nèi)唆姐， 沒有返回 Sentinel 發(fā)送的 PING 命令的回復(fù)拗慨， 或者返回一個錯誤， 那么 Sentinel 將這個服務(wù)器標記為主觀下線（SDOWN ）奉芦。
sentinel會以每秒一次的頻率向所有與其建立了命令連接的實例（master赵抢，從服務(wù)，其他sentinel）發(fā)ping命令仗阅，通過判斷ping回復(fù)是有效回復(fù)昌讲，還是無效回復(fù)來判斷實例時候在線（對該sentinel來說是“主觀在線”）。
sentinel配置文件中的down-after-milliseconds設(shè)置了判斷主觀下線的時間長度减噪，如果實例在down-after-milliseconds毫秒內(nèi)短绸，返回的都是無效回復(fù)，那么sentinel回認為該實例已（主觀）下線筹裕，修改其flags狀態(tài)為SRI_S_DOWN醋闭。如果多個sentinel監(jiān)視一個服務(wù)，有可能存在多個sentinel的down-after-milliseconds配置不同朝卒，這個在實際生產(chǎn)中要注意证逻。
客觀下線
客觀下線（Objectively Down， 簡稱 ODOWN）指的是多個 Sentinel 實例在對同一個服務(wù)器做出 SDOWN 判斷抗斤， 并且通過 SENTINEL is-master-down-by-addr 命令互相交流之后囚企， 得出的服務(wù)器下線判斷，然后開啟failover瑞眼。
客觀下線就是說只有在足夠數(shù)量的 Sentinel 都將一個服務(wù)器標記為主觀下線之后龙宏， 服務(wù)器才會被標記為客觀下線（ODOWN）。
只有當master被認定為客觀下線時伤疙，才會發(fā)生故障遷移银酗。
當sentinel監(jiān)視的某個服務(wù)主觀下線后辆影，sentinel會詢問其它監(jiān)視該服務(wù)的sentinel，看它們是否也認為該服務(wù)主觀下線黍特，接收到足夠數(shù)量（這個值可以配置）的sentinel判斷為主觀下線蛙讥，既任務(wù)該服務(wù)客觀下線，并對其做故障轉(zhuǎn)移操作灭衷。
sentinel通過發(fā)送 SENTINEL is-master-down-by-addr ip port current_epoch runid次慢，（ip：主觀下線的服務(wù)id，port：主觀下線的服務(wù)端口翔曲，current_epoch：sentinel的紀元经备，runid：*表示檢測服務(wù)下線狀態(tài)，如果是sentinel 運行id部默，表示用來選舉領(lǐng)頭sentinel）來詢問其它sentinel是否同意服務(wù)下線。
一個sentinel接收另一個sentinel發(fā)來的is-master-down-by-addr后造虎，提取參數(shù)傅蹂，根據(jù)ip和端口，檢測該服務(wù)時候在該sentinel主觀下線算凿，并且回復(fù)is-master-down-by-addr份蝴，回復(fù)包含三個參數(shù)：down_state（1表示已下線，0表示未下線）氓轰，leader_runid（領(lǐng)頭sentinal id）婚夫，leader_epoch（領(lǐng)頭sentinel紀元）。
sentinel接收到回復(fù)后署鸡，根據(jù)配置設(shè)置的下線最小數(shù)量案糙，達到這個值，既認為該服務(wù)客觀下線靴庆。
客觀下線條件只適用于主服務(wù)器： 對于任何其他類型的 Redis 實例时捌， Sentinel 在將它們判斷為下線前不需要進行協(xié)商， 所以從服務(wù)器或者其他 Sentinel 永遠不會達到客觀下線條件炉抒。只要一個 Sentinel 發(fā)現(xiàn)某個主服務(wù)器進入了客觀下線狀態(tài)奢讨， 這個 Sentinel 就可能會被其他 Sentinel 推選出， 并對失效的主服務(wù)器執(zhí)行自動故障遷移操作焰薄。
在redis-sentinel的conf文件里有這么兩個配置：
1）sentinel monitor <masterName> <ip> <port> <quorum>
四個參數(shù)含義：
masterName這個是對某個master+slave組合的一個區(qū)分標識（一套sentinel是可以監(jiān)聽多套master+slave這樣的組合的）拿诸。
ip 和 port 就是master節(jié)點的 ip 和 端口號。
quorum這個參數(shù)是進行客觀下線的一個依據(jù)塞茅，意思是至少有 quorum 個sentinel主觀的認為這個master有故障亩码，才會對這個master進行下線以及故障轉(zhuǎn)移。因為有的時候凡桥，某個sentinel節(jié)點可能因為自身網(wǎng)絡(luò)原因蟀伸，導(dǎo)致無法連接master，而此時master并沒有出現(xiàn)故障，所以這就需要多個sentinel都一致認為該master有問題啊掏，才可以進行下一步操作蠢络，這就保證了公平性和高可用。
2）sentinel down-after-milliseconds <masterName> <timeout>
這個配置其實就是進行主觀下線的一個依據(jù)迟蜜，masterName這個參數(shù)不用說了求类，timeout是一個毫秒值翎迁，表示：如果這臺sentinel超過timeout這個時間都無法連通master包括slave（slave不需要客觀下線，因為不需要故障轉(zhuǎn)移）的話，就會主觀認為該master已經(jīng)下線（實際下線需要客觀下線的判斷通過才會下線）
那么了讨，多個sentinel之間是如何達到共識的呢？
這就是依賴于前面說的第二個定時任務(wù)檩赢，某個sentinel先將master節(jié)點進行一個主觀下線闪盔，然后會將這個判定通過sentinel is-master-down-by-addr這個命令問對應(yīng)的節(jié)點是否也同樣認為該addr的master節(jié)點要做客觀下線。最后當達成這一共識的sentinel個數(shù)達到前面說的quorum設(shè)置的這個值時障斋，就會對該master節(jié)點下線進行故障轉(zhuǎn)移纵潦。quorum的值一般設(shè)置為sentinel個數(shù)的二分之一加1，例如3個sentinel就設(shè)置2垃环。
主觀下線（SDOWN）和客觀下線（ODOWN）的更多細節(jié)
sentinel對于不可用有兩種不同的看法邀层，一個叫主觀不可用(SDOWN),另外一個叫客觀不可用(ODOWN)。SDOWN是sentinel自己主觀上檢測到的關(guān)于master的狀態(tài)遂庄，ODOWN需要一定數(shù)量的sentinel達成一致意見才能認為一個master客觀上已經(jīng)宕掉寥院，各個sentinel之間通過命令SENTINEL is_master_down_by_addr來獲得其它sentinel對master的檢測結(jié)果。
從sentinel的角度來看涛目，如果發(fā)送了PING心跳后秸谢，在一定時間內(nèi)沒有收到合法的回復(fù)，就達到了SDOWN的條件霹肝。這個時間在配置中通過is-master-down-after-milliseconds參數(shù)配置钮追。
當sentinel發(fā)送PING后，以下回復(fù)之一都被認為是合法的：
PING replied with +PONG.
PING replied with -LOADING error.
PING replied with -MASTERDOWN error.
其它任何回復(fù)（或者根本沒有回復(fù)）都是不合法的阿迈。
從SDOWN切換到ODOWN不需要任何一致性算法元媚，只需要一個gossip協(xié)議：如果一個sentinel收到了足夠多的sentinel發(fā)來消息告訴它某個master已經(jīng)down掉了，SDOWN狀態(tài)就會變成ODOWN狀態(tài)苗沧。如果之后master可用了刊棕，這個狀態(tài)就會相應(yīng)地被清理掉。
正如之前已經(jīng)解釋過了待逞，真正進行failover需要一個授權(quán)的過程甥角，但是所有的failover都開始于一個ODOWN狀態(tài)。
ODOWN狀態(tài)只適用于master识樱，對于不是master的redis節(jié)點sentinel之間不需要任何協(xié)商嗤无，slaves和sentinel不會有ODOWN狀態(tài)震束。
配置版本號
為什么要先獲得大多數(shù)sentinel的認可時才能真正去執(zhí)行failover呢？
當一個sentinel被授權(quán)后当犯，它將會獲得宕掉的master的一份最新配置版本號垢村，當failover執(zhí)行結(jié)束以后，這個版本號將會被用于最新的配置嚎卫。因為大多數(shù)sentinel都已經(jīng)知道該版本號已經(jīng)被要執(zhí)行failover的sentinel拿走了嘉栓，所以其他的sentinel都不能再去使用這個版本號。這意味著拓诸，每次failover都會附帶有一個獨一無二的版本號侵佃。我們將會看到這樣做的重要性。而且奠支，sentinel集群都遵守一個規(guī)則：如果sentinel A推薦sentinel B去執(zhí)行failover馋辈，B會等待一段時間后，自行再次去對同一個master執(zhí)行failover倍谜，這個等待的時間是通過failover-timeout配置項去配置的首有。從這個規(guī)則可以看出，sentinel集群中的sentinel不會再同一時刻并發(fā)去failover同一個master枢劝，第一個進行failover的sentinel如果失敗了，另外一個將會在一定時間內(nèi)進行重新進行failover卜壕，以此類推您旁。
redis sentinel保證了活躍性：如果大多數(shù)sentinel能夠互相通信，最終將會有一個被授權(quán)去進行failover.
redis sentinel也保證了安全性：每個試圖去failover同一個master的sentinel都會得到一個獨一無二的版本號轴捎。
配置傳播
一旦一個sentinel成功地對一個master進行了failover鹤盒，它將會把關(guān)于master的最新配置通過廣播形式通知其它sentinel，其它的sentinel則更新對應(yīng)master的配置侦副。
一個faiover要想被成功實行侦锯，sentinel必須能夠向選為master的slave發(fā)送SLAVEOF NO ONE命令，然后能夠通過INFO命令看到新master的配置信息秦驯。
當將一個slave選舉為master并發(fā)送SLAVEOF NO ONE后尺碰，即使其它的slave還沒針對新master重新配置自己，failover也被認為是成功了的译隘，然后所有sentinels將會發(fā)布新的配置信息亲桥。
新配在集群中相互傳播的方式，就是為什么我們需要當一個sentinel進行failover時必須被授權(quán)一個版本號的原因固耘。
每個sentinel使用##發(fā)布/訂閱##的方式持續(xù)地傳播master的配置版本信息题篷，配置傳播的##發(fā)布/訂閱##管道是：sentinel:hello。
因為每一個配置都有一個版本號厅目，所以以版本號最大的那個為標準番枚。
舉個例子：
假設(shè)有一個名為mymaster的地址為192.168.10.202:6379法严。一開始，集群中所有的sentinel都知道這個地址葫笼，于是為mymaster的配置打上版本號1深啤。一段時候后mymaster死了，有一個sentinel被授權(quán)用版本號2對其進行failover渔欢。如果failover成功了墓塌，假設(shè)地址改為了192.168.10.202:9000，此時配置的版本號為2奥额，進行failover的sentinel會將新配置廣播給其他的sentinel苫幢，由于其他sentinel維護的版本號為1，發(fā)現(xiàn)新配置的版本號為2時垫挨，版本號變大了韩肝，說明配置更新了，于是就會采用最新的版本號為2的配置九榔。
這意味著sentinel集群保證了第二種活躍性：一個能夠互相通信的sentinel集群最終會采用版本號最高且相同的配置哀峻。
sentinel的"仲裁會"
前面我們談到，當一個master被sentinel集群監(jiān)控時哲泊，需要為它指定一個參數(shù)剩蟀，這個參數(shù)指定了當需要判決master為不可用，并且進行failover時切威，所需要的sentinel數(shù)量育特，可以稱這個參數(shù)為票數(shù)
不過，當failover主備切換真正被觸發(fā)后先朦，failover并不會馬上進行缰冤，還需要sentinel中的大多數(shù)sentinel授權(quán)后才可以進行failover。
當ODOWN時喳魏，failover被觸發(fā)棉浸。failover一旦被觸發(fā)，嘗試去進行failover的sentinel會去獲得“大多數(shù)”sentinel的授權(quán)（如果票數(shù)比大多數(shù)還要大的時候刺彩，則詢問更多的sentinel)
這個區(qū)別看起來很微妙迷郑，但是很容易理解和使用。例如创倔，集群中有5個sentinel三热，票數(shù)被設(shè)置為2，當2個sentinel認為一個master已經(jīng)不可用了以后三幻，將會觸發(fā)failover就漾，但是，進行failover的那個sentinel必須先獲得至少3個sentinel的授權(quán)才可以實行failover念搬。
如果票數(shù)被設(shè)置為5抑堡，要達到ODOWN狀態(tài)摆出，必須所有5個sentinel都主觀認為master為不可用，要進行failover首妖，那么得獲得所有5個sentinel的授權(quán)偎漫。
選舉領(lǐng)頭sentinel（即領(lǐng)導(dǎo)者選舉）
一個redis服務(wù)被判斷為客觀下線時，多個監(jiān)視該服務(wù)的sentinel協(xié)商有缆，選舉一個領(lǐng)頭sentinel象踊，對該redis服務(wù)進行故障轉(zhuǎn)移操作。選舉領(lǐng)頭sentinel遵循以下規(guī)則：
1）所有的sentinel都有公平被選舉成領(lǐng)頭的資格棚壁。
2）所有的sentinel都有且只有一次將某個sentinel選舉成領(lǐng)頭的機會（在一輪選舉中）杯矩，一旦選舉某個sentinel為領(lǐng)頭，不能更改袖外。
3）sentinel設(shè)置領(lǐng)頭sentinel是先到先得史隆，一旦當前sentinel設(shè)置了領(lǐng)頭sentinel，以后要求設(shè)置sentinel為領(lǐng)頭請求都會被拒絕曼验。
4）每個發(fā)現(xiàn)服務(wù)客觀下線的sentinel泌射，都會要求其他sentinel將自己設(shè)置成領(lǐng)頭。
5）當一個sentinel（源sentinel）向另一個sentinel（目sentinel）發(fā)送is-master-down-by-addr ip port current_epoch runid命令的時候鬓照，runid參數(shù)不是*熔酷，而是sentinel運行id，就表示源sentinel要求目標sentinel選舉其為領(lǐng)頭豺裆。
6）源sentinel會檢查目標sentinel對其要求設(shè)置成領(lǐng)頭的回復(fù)拒秘，如果回復(fù)的leader_runid和leader_epoch為源sentinel，表示目標sentinel同意將源sentinel設(shè)置成領(lǐng)頭留储。
7）如果某個sentinel被半數(shù)以上的sentinel設(shè)置成領(lǐng)頭，那么該sentinel既為領(lǐng)頭咙轩。
8）如果在限定時間內(nèi)获讳，沒有選舉出領(lǐng)頭sentinel，暫定一段時間活喊，再選舉丐膝。
為什么要選領(lǐng)導(dǎo)者？
簡單來說钾菊，就是因為只能有一個sentinel節(jié)點去完成故障轉(zhuǎn)移帅矗。
sentinel is-master-down-by-addr這個命令有兩個作用，一是確認下線判定煞烫，二是進行領(lǐng)導(dǎo)者選舉浑此。
選舉過程：
1）每個做主觀下線的sentinel節(jié)點向其他sentinel節(jié)點發(fā)送上面那條命令，要求將它設(shè)置為領(lǐng)導(dǎo)者滞详。
2）收到命令的sentinel節(jié)點如果還沒有同意過其他的sentinel發(fā)送的命令（還未投過票）凛俱，那么就會同意紊馏，否則拒絕。
3）如果該sentinel節(jié)點發(fā)現(xiàn)自己的票數(shù)已經(jīng)過半且達到了quorum的值蒲犬，就會成為領(lǐng)導(dǎo)者
4）如果這個過程出現(xiàn)多個sentinel成為領(lǐng)導(dǎo)者朱监，則會等待一段時間重新選舉。
Redis Sentinel的主從切換方案
Redis 2.8版開始正式提供名為Sentinel的主從切換方案原叮，通俗的來講赫编，Sentinel可以用來管理多個Redis服務(wù)器實例，可以實現(xiàn)一個功能上實現(xiàn)HA的集群奋隶，Sentinel主要負責(zé)三個方面的任務(wù)：
1）監(jiān)控（Monitoring）： Sentinel 會不斷地檢查你的主服務(wù)器和從服務(wù)器是否運作正常擂送。
2）提醒（Notification）： 當被監(jiān)控的某個 Redis 服務(wù)器出現(xiàn)問題時， Sentinel 可以通過 API 向管理員或者其他應(yīng)用程序發(fā)送通知达布。
3）自動故障遷移（Automatic failover）： 當一個主服務(wù)器不能正常工作時团甲， Sentinel 會開始一次自動故障遷移操作， 它會將失效主服務(wù)器的其中一個從服務(wù)器升級為新的主服務(wù)器黍聂， 并讓失效主服務(wù)器的其他從服務(wù)器改為復(fù)制新的主服務(wù)器躺苦； 當客戶端試圖連接失效的主服務(wù)器時， 集群也會向客戶端返回新主服務(wù)器的地址产还， 使得集群可以使用新主服務(wù)器代替失效服務(wù)器匹厘。
Redis Sentinel 是一個分布式系統(tǒng)， 可以在一個架構(gòu)中運行多個 Sentinel 進程（progress）脐区， 這些進程使用流言協(xié)議（gossip protocols)來接收關(guān)于主服務(wù)器是否下線的信息愈诚， 并使用投票協(xié)議（agreement protocols）來決定是否執(zhí)行自動故障遷移， 以及選擇哪個從服務(wù)器作為新的主服務(wù)器牛隅。
一個簡單的主從結(jié)構(gòu)加sentinel集群的架構(gòu)圖如下：
上圖是一主一從節(jié)點炕柔，加上兩個部署了sentinel的集群，sentinel集群之間會互相通信媒佣，溝通交流redis節(jié)點的狀態(tài)匕累，做出相應(yīng)的判斷并進行處理，這里的主觀下線狀態(tài)和客觀下線狀態(tài)是比較重要的狀態(tài)默伍，它們決定了是否進行故障轉(zhuǎn)移
可以 通過訂閱指定的頻道信息欢嘿，當服務(wù)器出現(xiàn)故障得時候通知管理員
客戶端可以將 Sentinel 看作是一個只提供了訂閱功能的 Redis 服務(wù)器，你不可以使用 PUBLISH 命令向這個服務(wù)器發(fā)送信息也糊，但你可以用 SUBSCRIBE 命令或者 PSUBSCRIBE 命令炼蹦， 通過訂閱給定的頻道來獲取相應(yīng)的事件提醒。 一個頻道能夠接收和這個頻道的名字相同的事件狸剃。 比如說掐隐， 名為 +sdown 的頻道就可以接收所有實例進入主觀下線（SDOWN）狀態(tài)的事件。
個人認為钞馁，Sentinel實現(xiàn)的最主要的一個功能就是能做到自動故障遷移瑟枫，即當某一個master掛了的時候斗搞，可以自動的將某一個slave提升為新的master，且原master的所有slave也都自動的將自己的master改為新提升的master慷妙，這樣我們的程序的可用性大大提高了僻焚。只要redis安裝完成，Sentinel就安裝完成了膝擂，Sentinel集成在redis里了虑啤。
Sentinel支持集群（可以部署在多臺機器上，也可以在一臺物理機上通過多端口實現(xiàn)偽集群部署）
很顯然架馋，只使用單個sentinel進程來監(jiān)控redis集群是不可靠的狞山，當sentinel進程宕掉后(sentinel本身也有單點問題，single-point-of-failure)整個集群系統(tǒng)將無法按照預(yù)期的方式運行叉寂。所以有必要將sentinel集群萍启，這樣有幾個好處：
1）即使有一些sentinel進程宕掉了，依然可以進行redis集群的主備切換屏鳍；
2）如果只有一個sentinel進程勘纯，如果這個進程運行出錯，或者是網(wǎng)絡(luò)堵塞钓瞭，那么將無法實現(xiàn)redis集群的主備切換（單點問題）;
3）如果有多個sentinel驳遵，redis的客戶端可以隨意地連接任意一個sentinel來獲得關(guān)于redis集群中的信息。
sentinel集群注意事項
1）只有Sentinel 集群中大多數(shù)服務(wù)器認定master主觀下線時master才會被認定為客觀下線山涡，才可以進行故障遷移堤结，也就是說，即使不管我們在sentinel monitor中設(shè)置的數(shù)是多少鸭丛，就算是滿足了該值竞穷，只要達不到大多數(shù)，就不會發(fā)生故障遷移鳞溉。
2）官方建議sentinel至少部署三臺瘾带，且分布在不同機器。這里主要考慮到sentinel的可用性穿挨，假如我們只部署了兩臺sentinel月弛，且quorum設(shè)置為1肴盏，也可以實現(xiàn)自動故障遷移科盛，但假如其中一臺sentinel掛了，就永遠不會觸發(fā)自動故障遷移菜皂，因為永遠達不到大多數(shù)sentinel認定master主觀下線了贞绵。
3）sentinel monitor配置中的master IP盡量不要寫127.0.0.1或localhost，因為客戶端恍飘，如jedis獲取master是根據(jù)這個獲取的榨崩，若這樣配置谴垫，jedis獲取的ip則是127.0.0.1，這樣就可能導(dǎo)致程序連接不上master
4）當sentinel 啟動后會自動的修改sentinel.conf文件母蛛，如已發(fā)現(xiàn)的master的slave信息翩剪，和集群中其它sentinel 的信息等,這樣即使重啟sentinel也能保持原來的狀態(tài)。注意彩郊，當集群服務(wù)器調(diào)整時前弯，如更換sentinel的機器，或者新配置一個sentinel秫逝，請不要直接復(fù)制原來運行過得sentinel配置文件恕出，因為其里面自動生成了以上說的那些信息，我們應(yīng)該復(fù)制一個新的配置文件或者把自動生成的信息給刪掉违帆。
5）當發(fā)生故障遷移的時候浙巫，master的變更記錄與slave更換master的修改會自動同步到redis的配置文件，這樣即使重啟redis也能保持變更后的狀態(tài)刷后。
每個 Sentinel 都需要定期執(zhí)行的任務(wù)
每個 Sentinel 以每秒鐘一次的頻率向它所知的主服務(wù)器的畴、從服務(wù)器以及其他 Sentinel 實例發(fā)送一個 PING 命令。
如果一個實例（instance）距離最后一次有效回復(fù) PING 命令的時間超過 down-after-milliseconds 選項所指定的值惠险， 那么這個實例會被 Sentinel 標記為主觀下線苗傅。 一個有效回復(fù)可以是： +PONG 、 -LOADING 或者 -MASTERDOWN 班巩。
如果一個主服務(wù)器被標記為主觀下線渣慕， 那么正在監(jiān)視這個主服務(wù)器的所有 Sentinel 要以每秒一次的頻率確認主服務(wù)器的確進入了主觀下線狀態(tài)。
如果一個主服務(wù)器被標記為主觀下線抱慌， 并且有足夠數(shù)量的 Sentinel （至少要達到配置文件指定的數(shù)量）在指定的時間范圍內(nèi)同意這一判斷逊桦， 那么這個主服務(wù)器被標記為客觀下線。
在一般情況下抑进， 每個 Sentinel 會以每 10 秒一次的頻率向它已知的所有主服務(wù)器和從服務(wù)器發(fā)送 INFO 命令奶稠。 當一個主服務(wù)器被 Sentinel 標記為客觀下線時， Sentinel 向下線主服務(wù)器的所有從服務(wù)器發(fā)送 INFO 命令的頻率會從 10 秒一次改為每秒一次巴席。
當沒有足夠數(shù)量的 Sentinel 同意主服務(wù)器已經(jīng)下線疼进， 主服務(wù)器的客觀下線狀態(tài)就會被移除。 當主服務(wù)器重新向 Sentinel 的PING 命令返回有效回復(fù)時信殊， 主服務(wù)器的主管下線狀態(tài)就會被移除炬称。
Sentinel之間和Slaves之間的自動發(fā)現(xiàn)機制
雖然sentinel集群中各個sentinel都互相連接彼此來檢查對方的可用性以及互相發(fā)送消息。但是你不用在任何一個sentinel配置任何其它的sentinel的節(jié)點涡拘。因為sentinel利用了master的發(fā)布/訂閱機制去自動發(fā)現(xiàn)其它也監(jiān)控了統(tǒng)一master的sentinel節(jié)點玲躯。
通過向名為sentinel:hello的管道中發(fā)送消息來實現(xiàn)。
同樣，你也不需要在sentinel中配置某個master的所有slave的地址跷车，sentinel會通過詢問master來得到這些slave的地址的棘利。
每個sentinel通過向每個master和slave的發(fā)布/訂閱頻道sentinel:hello每秒發(fā)送一次消息，來宣布它的存在朽缴。
每個sentinel也訂閱了每個master和slave的頻道sentinel:hello的內(nèi)容善玫，來發(fā)現(xiàn)未知的sentinel，當檢測到了新的sentinel密强，則將其加入到自身維護的master監(jiān)控列表中蝌焚。
每個sentinel發(fā)送的消息中也包含了其當前維護的最新的master配置。如果某個sentinel發(fā)現(xiàn)
自己的配置版本低于接收到的配置版本誓斥，則會用新的配置更新自己的master配置只洒。
在為一個master添加一個新的sentinel前，sentinel總是檢查是否已經(jīng)有sentinel與新的sentinel的進程號或者是地址是一樣的劳坑。如果是那樣毕谴，這個sentinel將會被刪除，而把新的sentinel添加上去距芬。
sentinel和redis身份驗證
當一個master配置為需要密碼才能連接時涝开，客戶端和slave在連接時都需要提供密碼。
master通過requirepass設(shè)置自身的密碼框仔，不提供密碼無法連接到這個master舀武。
slave通過masterauth來設(shè)置訪問master時的密碼。
但是當使用了sentinel時离斩，由于一個master可能會變成一個slave银舱，一個slave也可能會變成master，所以需要同時設(shè)置上述兩個配置項跛梗。
Sentinel API
在默認情況下寻馏， Sentinel 使用 TCP 端口 26379 （普通 Redis 服務(wù)器使用的是 6379 ）。Sentinel 接受 Redis 協(xié)議格式的命令請求核偿， 所以你可以使用 redis-cli 或者任何其他 Redis 客戶端來與 Sentinel 進行通訊诚欠。有兩種方式可以和 Sentinel 進行通訊：
1）是通過直接發(fā)送命令來查詢被監(jiān)視 Redis 服務(wù)器的當前狀態(tài)， 以及 Sentinel 所知道的關(guān)于其他 Sentinel 的信息漾岳， 諸如此類轰绵。
2）是使用發(fā)布與訂閱功能， 通過接收 Sentinel 發(fā)送的通知： 當執(zhí)行故障轉(zhuǎn)移操作尼荆， 或者某個被監(jiān)視的服務(wù)器被判斷為主觀下線或者客觀下線時左腔， Sentinel 就會發(fā)送相應(yīng)的信息。
Sentinel命令（即登錄到sentinel節(jié)點后執(zhí)行的命令耀找，比如執(zhí)行"redis-cli -h 192.168.10.203 -p 26379"命令后翔悠，才可以執(zhí)行下面命令）
PING ：返回 PONG 。
SENTINEL masters ：列出所有被監(jiān)視的主服務(wù)器野芒，以及這些主服務(wù)器的當前狀態(tài)蓄愁；
SENTINEL slaves <master name> ：列出給定主服務(wù)器的所有從服務(wù)器，以及這些從服務(wù)器的當前狀態(tài)狞悲；
SENTINEL get-master-addr-by-name <master name> ： 返回給定名字的主服務(wù)器的 IP 地址和端口號撮抓。 如果這個主服務(wù)器正在執(zhí)行故障轉(zhuǎn)移操作， 或者針對這個主服務(wù)器的故障轉(zhuǎn)移操作已經(jīng)完成摇锋， 那么這個命令返回新的主服務(wù)器的 IP 地址和端口號丹拯；
SENTINEL reset <pattern>： 重置所有名字和給定模式 pattern 相匹配的主服務(wù)器。 pattern 參數(shù)是一個 Glob 風(fēng)格的模式荸恕。 重置操作清楚主服務(wù)器目前的所有狀態(tài)乖酬， 包括正在執(zhí)行中的故障轉(zhuǎn)移， 并移除目前已經(jīng)發(fā)現(xiàn)和關(guān)聯(lián)的融求， 主服務(wù)器的所有從服務(wù)器和 Sentinel 咬像；
SENTINEL failover <master name> ： 當主服務(wù)器失效時， 在不詢問其他 Sentinel 意見的情況下生宛， 強制開始一次自動故障遷移县昂。 （不過發(fā)起故障轉(zhuǎn)移的 Sentinel 會向其他 Sentinel 發(fā)送一個新的配置，其他 Sentinel 會根據(jù)這個配置進行相應(yīng)的更新）
SENTINEL MONITOR <name> <ip> <port> <quorum> 這個命令告訴sentinel去監(jiān)聽一個新的master
SENTINEL REMOVE <name> 命令sentinel放棄對某個master的監(jiān)聽
SENTINEL SET <name> <option> <value> 這個命令很像Redis的CONFIG SET命令陷舅，用來改變指定master的配置倒彰。支持多個<option><value>。例如以下實例：SENTINEL SET objects-cache-master down-after-milliseconds 1000
只要是配置文件中存在的配置項莱睁，都可以用SENTINEL SET命令來設(shè)置待讳。這個還可以用來設(shè)置master的屬性，比如說quorum(票數(shù))仰剿，而不需要先刪除master耙箍，再重新添加master。例如：SENTINEL SET objects-cache-master quorum 5
客戶端可以通過SENTINEL get-master-addr-by-name <master name>獲取當前的主服務(wù)器IP地址和端口號酥馍，以及SENTINEL slaves <master name>獲取所有的Slaves信息辩昆。
[root@redis-master ~]# redis-cli -h 192.168.10.202 -p 6379 INFO|grep role
role:slave
[root@redis-master ~]# redis-cli -h 192.168.10.203 -p 6379 INFO|grep role
role:slave
[root@redis-master ~]# redis-cli -h 192.168.10.205 -p 6379 INFO|grep role
role:master
登錄任意一個節(jié)點的sentinel，進行相關(guān)命令的操作（下面命令例子中的redisMaster是sentinel監(jiān)控redis主從狀態(tài)時定義的master名稱）
1）sentinel masters 羅列所有sentinel 監(jiān)視相關(guān)的master
[root@redis-master ~]# redis-cli -h 192.168.10.205 -p 26379
192.168.10.205:26379> sentinel masters
2）sentinel master masterName 列出一個master相關(guān)的的信息
[root@redis-master ~]# redis-cli -h 192.168.10.205 -p 26379
192.168.10.205:26379> sentinel master redisMaster
3）sentinel slaves masterName 列出一個master相應(yīng)的slave組相關(guān)的數(shù)據(jù)
[root@redis-master ~]# redis-cli -h 192.168.10.205 -p 26379
192.168.10.205:26379> sentinel slaves redisMaster
4）sentinel sentinels masterName 列出master相關(guān)的sentinels組其他相關(guān)的信息
[root@redis-master ~]# redis-cli -h 192.168.10.205 -p 26379
192.168.10.205:26379> sentinel sentinels redisMaster
5）sentinel get-master-addr-by-name masterName 獲取master-name相關(guān)的 ip addr 的信息
[root@redis-master ~]# redis-cli -h 192.168.10.205 -p 26379
192.168.10.205:26379> sentinel get-master-addr-by-name redisMaster
1) "192.168.10.205"
2) "6379"
增加或刪除Sentinel
由于有sentinel自動發(fā)現(xiàn)機制旨袒，所以添加一個sentinel到你的集群中非常容易汁针，你所需要做的只是監(jiān)控到某個Master上，然后新添加的sentinel就能獲得其他sentinel的信息以及master所有的slaves砚尽。
如果你需要添加多個sentinel施无，建議你一個接著一個添加，這樣可以預(yù)防網(wǎng)絡(luò)隔離帶來的問題必孤。你可以每個30秒添加一個sentinel猾骡。最后你可以用SENTINEL MASTER mastername來檢查一下是否所有的sentinel都已經(jīng)監(jiān)控到了master瑞躺。
刪除一個sentinel顯得有點復(fù)雜：因為sentinel永遠不會刪除一個已經(jīng)存在過的sentinel，即使它已經(jīng)與組織失去聯(lián)系很久了兴想。
要想刪除一個sentinel幢哨，應(yīng)該遵循如下步驟：
1）停止所要刪除的sentinel
2）發(fā)送一個SENTINEL RESET * 命令給所有其它的sentinel實例，如果你想要重置指定master上面的sentinel嫂便，只需要把*號改為特定的名字捞镰，注意，需要一個接一個發(fā)毙替，每次發(fā)送的間隔不低于30秒岸售。
3）檢查一下所有的sentinels是否都有一致的當前sentinel數(shù)。使用SENTINEL MASTER mastername 來查詢厂画。
刪除舊master或者不可達slave
sentinel永遠會記錄好一個Master的slaves凸丸，即使slave已經(jīng)與組織失聯(lián)好久了。這是很有用的袱院，因為sentinel集群必須有能力把一個恢復(fù)可用的slave進行重新配置甲雅。
并且，failover后坑填，失效的master將會被標記為新master的一個slave抛人，這樣的話，當它變得可用時脐瑰，就會從新master上復(fù)制數(shù)據(jù)妖枚。
然后，有時候你想要永久地刪除掉一個slave(有可能它曾經(jīng)是個master)苍在，你只需要發(fā)送一個SENTINEL RESET master命令給所有的sentinels绝页，它們將會更新列表里能夠正確地復(fù)制master數(shù)據(jù)的slave。
發(fā)布與訂閱信息（sentinel的日志文件里可以看到這些信息）
客戶端可以將 Sentinel 看作是一個只提供了訂閱功能的 Redis 服務(wù)器： 你不可以使用 PUBLISH 命令向這個服務(wù)器發(fā)送信息寂恬， 但你可以用 SUBSCRIBE 命令或者 PSUBSCRIBE 命令续誉， 通過訂閱給定的頻道來獲取相應(yīng)的事件提醒。
一個頻道能夠接收和這個頻道的名字相同的事件初肉。 比如說酷鸦， 名為 +sdown 的頻道就可以接收所有實例進入主觀下線（SDOWN）狀態(tài)的事件。
通過執(zhí)行 "PSUBSCRIBE * "命令可以接收所有事件信息（即訂閱所有消息）牙咏。
以下列出的是客戶端可以通過訂閱來獲得的頻道和信息的格式： 第一個英文單詞是頻道/事件的名字臼隔， 其余的是數(shù)據(jù)的格式。
注意妄壶， 當格式中包含 instance details 字樣時摔握， 表示頻道所返回的信息中包含了以下用于識別目標實例的內(nèi)容.
以下是所有可以收到的消息的消息格式，如果你訂閱了所有消息的話丁寄。第一個單詞是頻道的名字氨淌，其它是數(shù)據(jù)的格式泊愧。
注意：以下的instance details的格式是：
<instance-type> <name> <ip> <port> @ <master-name> <master-ip> <master-port>
如果這個redis實例是一個master，那么@之后的消息就不會顯示盛正。
+reset-master <instance details> -- 當master被重置時.
+slave <instance details> -- 當檢測到一個slave并添加進slave列表時.
+failover-state-reconf-slaves <instance details> -- Failover狀態(tài)變?yōu)閞econf-slaves狀態(tài)時
+failover-detected <instance details> -- 當failover發(fā)生時
+slave-reconf-sent <instance details> -- sentinel發(fā)送SLAVEOF命令把它重新配置時
+slave-reconf-inprog <instance details> -- slave被重新配置為另外一個master的slave删咱，但數(shù)據(jù)復(fù)制還未發(fā)生時。
+slave-reconf-done <instance details> -- slave被重新配置為另外一個master的slave并且數(shù)據(jù)復(fù)制已經(jīng)與master同步時蛮艰。
-dup-sentinel <instance details> -- 刪除指定master上的冗余sentinel時 (當一個sentinel重新啟動時，可能會發(fā)生這個事件).
+sentinel <instance details> -- 當master增加了一個sentinel時雀彼。
+sdown <instance details> -- 進入SDOWN狀態(tài)時;
-sdown <instance details> -- 離開SDOWN狀態(tài)時壤蚜。
+odown <instance details> -- 進入ODOWN狀態(tài)時。
-odown <instance details> -- 離開ODOWN狀態(tài)時徊哑。
+new-epoch <instance details> -- 當前配置版本被更新時袜刷。
+try-failover <instance details> -- 達到failover條件，正等待其他sentinel的選舉莺丑。
+elected-leader <instance details> -- 被選舉為去執(zhí)行failover的時候著蟹。
+failover-state-select-slave <instance details> -- 開始要選擇一個slave當選新master時。
no-good-slave <instance details> -- 沒有合適的slave來擔(dān)當新master
selected-slave <instance details> -- 找到了一個適合的slave來擔(dān)當新master
failover-state-send-slaveof-noone <instance details> -- 當把選擇為新master的slave的身份進行切換的時候梢莽。
failover-end-for-timeout <instance details> -- failover由于超時而失敗時萧豆。
failover-end <instance details> -- failover成功完成時。
switch-master <master name> <oldip> <oldport> <newip> <newport> -- 當master的地址發(fā)生變化時昏名。通常這是客戶端最感興趣的消息了涮雷。
+tilt -- 進入Tilt模式。
-tilt -- 退出Tilt模式轻局。
可以看出洪鸭，使用Sentinel命令和發(fā)布訂閱兩種機制就能很好的實現(xiàn)和客戶端的集成整合：
使用get-master-addr-by-name和slaves指令可以獲取當前的Master和Slaves的地址和信息；而當發(fā)生故障轉(zhuǎn)移時仑扑，即Master發(fā)生切換览爵，可以通過訂閱的+switch-master事件獲得最新的Master信息。
sentinel.conf中的notification-script
在sentinel.conf中可以配置多個sentinel notification-script <master name> <shell script-path>, 如sentinel notification-script mymaster ./check.sh
這個是在群集failover時會觸發(fā)執(zhí)行指定的腳本镇饮。腳本的執(zhí)行結(jié)果若為1蜓竹，即稍后重試（最大重試次數(shù)為10）；若為2储藐，則執(zhí)行結(jié)束梅肤。并且腳本最大執(zhí)行時間為60秒，超時會被終止執(zhí)行邑茄。
目前會存在該腳本被執(zhí)行多次的問題姨蝴，網(wǎng)上查找資料獲得的解釋是：腳本分為兩個級別， SENTINEL_LEADER 和 SENTINEL_OBSERVER 肺缕，前者僅由領(lǐng)頭 Sentinel 執(zhí)行（一個 Sentinel）左医，而后者由監(jiān)視同一個 master 的所有 Sentinel 執(zhí)行（多個 Sentinel）授帕。
無failover時的配置糾正
即使當前沒有failover正在進行，sentinel依然會使用當前配置去設(shè)置監(jiān)控的master浮梢。特別是：
1）根據(jù)最新配置確認為slaves的節(jié)點卻聲稱自己是master(上文例子中被網(wǎng)絡(luò)隔離后的的redis3)跛十，這時它們會被重新配置為當前master的slave。
2）如果slaves連接了一個錯誤的master秕硝，將會被改正過來芥映，連接到正確的master。
Slave選舉與優(yōu)先級
當一個sentinel準備好了要進行failover远豺，并且收到了其他sentinel的授權(quán)奈偏，那么就需要選舉出一個合適的slave來做為新的master。
slave的選舉主要會評估slave的以下幾個方面：
1）與master斷開連接的次數(shù)
2）Slave的優(yōu)先級
3）數(shù)據(jù)復(fù)制的下標(用來評估slave當前擁有多少master的數(shù)據(jù))
4）進程ID
如果一個slave與master失去聯(lián)系超過10次躯护，并且每次都超過了配置的最大失聯(lián)時間(down-after-milliseconds)惊来，如果sentinel在進行failover時發(fā)現(xiàn)slave失聯(lián)，那么這個slave就會被sentinel認為不適合用來做新master的棺滞。
更嚴格的定義是裁蚁，如果一個slave持續(xù)斷開連接的時間超過
(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state
就會被認為失去選舉資格。
符合上述條件的slave才會被列入master候選人列表继准，并根據(jù)以下順序來進行排序：
1）sentinel首先會根據(jù)slaves的優(yōu)先級來進行排序枉证，優(yōu)先級越小排名越靠前。
2）如果優(yōu)先級相同移必，則查看復(fù)制的下標刽严，哪個從master接收的復(fù)制數(shù)據(jù)多，哪個就靠前避凝。
3）如果優(yōu)先級和下標都相同舞萄，就選擇進程ID較小的那個。
一個redis無論是master還是slave管削，都必須在配置中指定一個slave優(yōu)先級倒脓。要注意到master也是有可能通過failover變成slave的。
如果一個redis的slave優(yōu)先級配置為0含思，那么它將永遠不會被選為master崎弃。但是它依然會從master哪里復(fù)制數(shù)據(jù)。
故障轉(zhuǎn)移
所謂故障轉(zhuǎn)移就是當master宕機含潘，選一個合適的slave來晉升為master的操作饲做，redis-sentinel會自動完成這個，不需要我們手動來實現(xiàn)遏弱。
一次故障轉(zhuǎn)移操作大致分為以下流程：
發(fā)現(xiàn)主服務(wù)器已經(jīng)進入客觀下線狀態(tài)盆均。
對我們的當前集群進行自增漱逸， 并嘗試在這個集群中當選。
如果當選失敗肮砾， 那么在設(shè)定的故障遷移超時時間的兩倍之后仗处， 重新嘗試當選眯勾。 如果當選成功吃环， 那么執(zhí)行以下步驟：
選出一個從服務(wù)器模叙，并將它升級為主服務(wù)器故觅。
向被選中的從服務(wù)器發(fā)送 SLAVEOF NO ONE 命令输吏，讓它轉(zhuǎn)變?yōu)橹鞣?wù)器拄氯。
通過發(fā)布與訂閱功能， 將更新后的配置傳播給所有其他 Sentinel 姐霍， 其他 Sentinel 對它們自己的配置進行更新镊折。
向已下線主服務(wù)器的從服務(wù)器發(fā)送 SLAVEOF 命令骂因， 讓它們?nèi)?fù)制新的主服務(wù)器塘装。
當所有從服務(wù)器都已經(jīng)開始復(fù)制新的主服務(wù)器時， 領(lǐng)頭 Sentinel 終止這次故障遷移操作阴幌。
每當一個 Redis 實例被重新配置（reconfigured） —— 無論是被設(shè)置成主服務(wù)器、從服務(wù)器议忽、又或者被設(shè)置成其他主服務(wù)器的從服務(wù)器 —— Sentinel 都會向被重新配置的實例發(fā)送一個 CONFIG REWRITE 命令， 從而確保這些配置會持久化在硬盤里。
Sentinel 使用以下規(guī)則來選擇新的主服務(wù)器：
在失效主服務(wù)器屬下的從服務(wù)器當中芍锚， 那些被標記為主觀下線、已斷線逃魄、或者最后一次回復(fù) PING 命令的時間大于五秒鐘的從服務(wù)器都會被淘汰。
在失效主服務(wù)器屬下的從服務(wù)器當中， 那些與失效主服務(wù)器連接斷開的時長超過 down-after 選項指定的時長十倍的從服務(wù)器都會被淘汰柳弄。
在經(jīng)歷了以上兩輪淘汰之后剩下來的從服務(wù)器中嚣伐， 我們選出復(fù)制偏移量（replication offset）最大的那個從服務(wù)器作為新的主服務(wù)器； 如果復(fù)制偏移量不可用， 或者從服務(wù)器的復(fù)制偏移量相同拱层， 那么帶有最小運行 ID 的那個從服務(wù)器成為新的主服務(wù)器。
Sentinel 自動故障遷移的一致性特質(zhì)
Sentinel 自動故障遷移使用 Raft 算法來選舉領(lǐng)頭（leader） Sentinel ， 從而確保在一個給定的紀元（epoch）里茬高， 只有一個領(lǐng)頭產(chǎn)生丽猬。
這表示在同一個紀元中谬以， 不會有兩個 Sentinel 同時被選中為領(lǐng)頭， 并且各個 Sentinel 在同一個紀元中只會對一個領(lǐng)頭進行投票。
更高的配置紀元總是優(yōu)于較低的紀元炕檩， 因此每個 Sentinel 都會主動使用更新的紀元來代替自己的配置泉沾。
簡單來說， 可以將 Sentinel 配置看作是一個帶有版本號的狀態(tài)。 一個狀態(tài)會以最后寫入者勝出（last-write-wins）的方式（也即是潭袱，最新的配置總是勝出）傳播至所有其他 Sentinel 。
舉個例子， 當出現(xiàn)網(wǎng)絡(luò)分割（network partitions）時晕窑， 一個 Sentinel 可能會包含了較舊的配置截汪， 而當這個 Sentinel 接到其他 Sentinel 發(fā)來的版本更新的配置時阳柔， Sentinel 就會對自己的配置進行更新。
如果要在網(wǎng)絡(luò)分割出現(xiàn)的情況下仍然保持一致性霍转， 那么應(yīng)該使用 min-slaves-to-write 選項， 讓主服務(wù)器在連接的從實例少于給定數(shù)量時停止執(zhí)行寫操作委造， 與此同時， 應(yīng)該在每個運行 Redis 主服務(wù)器或從服務(wù)器的機器上運行 Redis Sentinel 進程。
Sentinel 狀態(tài)的持久化
Sentinel 的狀態(tài)會被持久化在 Sentinel 配置文件里面跑筝。每當 Sentinel 接收到一個新的配置妓忍， 或者當領(lǐng)頭 Sentinel 為主服務(wù)器創(chuàng)建一個新的配置時定罢， 這個配置會與配置紀元一起被保存到磁盤里面。這意味著停止和重啟 Sentinel 進程都是安全的凌停。
Sentinel 在非故障遷移的情況下對實例進行重新配置
即使沒有自動故障遷移操作在進行台诗， Sentinel 總會嘗試將當前的配置設(shè)置到被監(jiān)視的實例上面。 特別是：
根據(jù)當前的配置， 如果一個從服務(wù)器被宣告為主服務(wù)器事哭， 那么它會代替原有的主服務(wù)器， 成為新的主服務(wù)器蓄坏， 并且成為原有主服務(wù)器的所有從服務(wù)器的復(fù)制對象。
那些連接了錯誤主服務(wù)器的從服務(wù)器會被重新配置， 使得這些從服務(wù)器會去復(fù)制正確的主服務(wù)器。
不過乳丰， 在以上這些條件滿足之后夜郁， Sentinel 在對實例進行重新配置之前仍然會等待一段足夠長的時間屎即， 確保可以接收到其他 Sentinel 發(fā)來的配置更新， 從而避免自身因為保存了過期的配置而對實例進行了不必要的重新配置谤逼。
總結(jié)來說，故障轉(zhuǎn)移分為三個步驟：
1）從下線的主服務(wù)的所有從服務(wù)里面挑選一個從服務(wù)，將其轉(zhuǎn)成主服務(wù)
sentinel狀態(tài)數(shù)據(jù)結(jié)構(gòu)中保存了主服務(wù)的所有從服務(wù)信息，領(lǐng)頭sentinel按照如下的規(guī)則從從服務(wù)列表中挑選出新的主服務(wù)跨晴；
刪除列表中處于下線狀態(tài)的從服務(wù)费封；
刪除最近5秒沒有回復(fù)過領(lǐng)頭sentinel info信息的從服務(wù)焚鹊；
刪除與已下線的主服務(wù)斷開連接時間超過 down-after-milliseconds*10毫秒的從服務(wù)喉恋，這樣就能保留從的數(shù)據(jù)比較新（沒有過早的與主斷開連接）胳蛮；
領(lǐng)頭sentinel從剩下的從列表中選擇優(yōu)先級高的，如果優(yōu)先級一樣，選擇偏移量最大的（偏移量大說明復(fù)制的數(shù)據(jù)比較新）曲稼，如果偏移量一樣娘摔，選擇運行id最小的從服務(wù)鸭津。
2）已下線主服務(wù)的所有從服務(wù)改為復(fù)制新的主服務(wù)
挑選出新的主服務(wù)之后晒奕，領(lǐng)頭sentinel 向原主服務(wù)的從服務(wù)發(fā)送 slaveof 新主服務(wù) 的命令，復(fù)制新master杆融。
3）將已下線的主服務(wù)設(shè)置成新的主服務(wù)的從服務(wù)淘捡，當其回復(fù)正常時，復(fù)制新的主服務(wù)乌逐，變成新的主服務(wù)的從服務(wù)
同理灿渴，當已下線的服務(wù)重新上線時缚窿，sentinel會向其發(fā)送slaveof命令，讓其成為新主的從扫茅。
溫馨提示：還可以向任意sentinel發(fā)生sentinel failover <masterName> 進行手動故障轉(zhuǎn)移爆雹，這樣就不需要經(jīng)過上述主客觀和選舉的過程。
sentinel.conf文件配置參數(shù)解釋
1）sentinel monitor mymaster 192.168.10.202 6379 2
Sentine監(jiān)聽的maste地址，第一個參數(shù)是給master起的名字灿意，第二個參數(shù)為master IP缤剧，第三個為master端口，第四個為當該master掛了的時候域慷，若想將該master判為失效荒辕，
在Sentine集群中必須至少2個Sentine同意才行犹褒，只要該數(shù)量不達標抵窒，則就不會發(fā)生故障遷移。也就是說只要有2個sentinel認為master下線叠骑，就認為該master客觀下線李皇，
啟動failover并選舉產(chǎn)生新的master。通常最后一個參數(shù)不能多于啟動的sentinel實例數(shù)座云。
這個配置是sentinel需要監(jiān)控的master/slaver信息疙赠，格式為sentinel monitor <mastername> <masterIP> <masterPort> <quorum>
其中<quorum>應(yīng)該小于集群中slave的個數(shù)付材，當失效的節(jié)點數(shù)超過了<quorum>,則認為整個體系結(jié)構(gòu)失效
不過要注意朦拖， 無論你設(shè)置要多少個 Sentinel 同意才能判斷一個服務(wù)器失效圃阳， 一個 Sentinel 都需要獲得系統(tǒng)中多數(shù)（majority） Sentinel 的支持， 才能發(fā)起一次自動故障遷移璧帝，
并預(yù)留一個給定的配置紀元 （configuration Epoch 捍岳，一個配置紀元就是一個新主服務(wù)器配置的版本號）。
換句話說睬隶， 在只有少數(shù)（minority） Sentinel 進程正常運作的情況下锣夹， Sentinel 是不能執(zhí)行自動故障遷移的。
-----------------------------------------------------------------------------------------------
2）sentinel down-after-milliseconds mymaster 30000
表示master被當前sentinel實例認定為失效的間隔時間苏潜。
master在多長時間內(nèi)一直沒有給Sentine返回有效信息银萍，則認定該master主觀下線。也就是說如果多久沒聯(lián)系上redis-servevr恤左，認為這個redis-server進入到失效（SDOWN）狀態(tài)贴唇。
如果服務(wù)器在給定的毫秒數(shù)之內(nèi)， 沒有返回 Sentinel 發(fā)送的 PING 命令的回復(fù)飞袋， 或者返回一個錯誤戳气， 那么 Sentinel 將這個服務(wù)器標記為主觀下線（subjectively down，簡稱 SDOWN ）巧鸭。
不過只有一個 Sentinel 將服務(wù)器標記為主觀下線并不一定會引起服務(wù)器的自動故障遷移： 只有在足夠數(shù)量的 Sentinel 都將一個服務(wù)器標記為主觀下線之后瓶您， 服務(wù)器才會被標記為客觀下線
（objectively down， 簡稱 ODOWN ）纲仍， 這時自動故障遷移才會執(zhí)行呀袱。
將服務(wù)器標記為客觀下線所需的 Sentinel 數(shù)量由對主服務(wù)器的配置決定。
-----------------------------------------------------------------------------------------------
3）sentinel parallel-syncs mymaster 2
當在執(zhí)行故障轉(zhuǎn)移時郑叠，設(shè)置幾個slave同時進行切換master夜赵，該值越大，則可能就有越多的slave在切換master時不可用锻拘，可以將該值設(shè)置為1油吭，即一個一個來，這樣在某個
slave進行切換master同步數(shù)據(jù)時署拟，其余的slave還能正常工作婉宰，以此保證每次只有一個從服務(wù)器處于不能處理命令請求的狀態(tài)。
parallel-syncs 選項指定了在執(zhí)行故障轉(zhuǎn)移時推穷， 最多可以有多少個從服務(wù)器同時對新的主服務(wù)器進行同步心包， 這個數(shù)字越小， 完成故障轉(zhuǎn)移所需的時間就越長馒铃。
如果從服務(wù)器被設(shè)置為允許使用過期數(shù)據(jù)集（參見對 redis.conf 文件中對 slave-serve-stale-data 選項的說明）蟹腾， 那么你可能不希望所有從服務(wù)器都在同一時間向新的主服務(wù)器發(fā)送同步請求痕惋，
因為盡管復(fù)制過程的絕大部分步驟都不會阻塞從服務(wù)器， 但從服務(wù)器在載入主服務(wù)器發(fā)來的 RDB 文件時娃殖， 仍然會造成從服務(wù)器在一段時間內(nèi)不能處理命令請求： 如果全部從服務(wù)器一起對新的主
服務(wù)器進行同步值戳， 那么就可能會造成所有從服務(wù)器在短時間內(nèi)全部不可用的情況出現(xiàn)。
當新master產(chǎn)生時炉爆，同時進行"slaveof"到新master并進行"SYNC"的slave個數(shù)堕虹。
默認為1,建議保持默認值
在salve執(zhí)行salveof與同步時，將會終止客戶端請求芬首。
此值較大赴捞，意味著"集群"終止客戶端請求的時間總和和較大。
此值較小,意味著"集群"在故障轉(zhuǎn)移期間郁稍，多個salve向客戶端提供服務(wù)時仍然使用舊數(shù)據(jù)赦政。
-----------------------------------------------------------------------------------------------
4）sentinel can-failover mymaster yes
在sentinel檢測到O_DOWN后，是否對這臺redis啟動failover機制
-----------------------------------------------------------------------------------------------
5）sentinel auth-pass mymaster 20180408
設(shè)置sentinel連接的master和slave的密碼耀怜，這個需要和redis.conf文件中設(shè)置的密碼一樣
-----------------------------------------------------------------------------------------------
6）sentinel failover-timeout mymaster 180000
failover過期時間恢着，當failover開始后，在此時間內(nèi)仍然沒有觸發(fā)任何failover操作封寞，當前sentinel將會認為此次failoer失敗然评。
執(zhí)行故障遷移超時時間，即在指定時間內(nèi)沒有大多數(shù)的sentinel 反饋master下線狈究，該故障遷移計劃則失效
-----------------------------------------------------------------------------------------------
7）sentinel config-epoch mymaster 0
選項指定了在執(zhí)行故障轉(zhuǎn)移時碗淌， 最多可以有多少個從服務(wù)器同時對新的主服務(wù)器進行同步。這個數(shù)字越小抖锥， 完成故障轉(zhuǎn)移所需的時間就越長亿眠。
-----------------------------------------------------------------------------------------------
8）sentinel notification-script mymaster /var/redis/notify.sh
當failover時，可以指定一個"通知"腳本用來告知當前集群的情況磅废。
腳本被允許執(zhí)行的最大時間為60秒纳像，如果超時，腳本將會被終止(KILL)
-----------------------------------------------------------------------------------------------
9）sentinel leader-epoch mymaster 0
同時一時間最多0個slave可同時更新配置,建議數(shù)字不要太大,以免影響正常對外提供服務(wù)拯勉。
基于以上細節(jié)知識梳理竟趾，總結(jié)出sentinel的工作原理
首先要能理解SDOWN和ODOWN這兩個詞的含義，上面已經(jīng)詳細介紹了它們倆宫峦。在此再提一下：
SDOWN:subjectively down,直接翻譯的為"主觀"失效,即當前sentinel實例認為某個redis服務(wù)為"不可用"狀態(tài).
ODOWN:objectively down,直接翻譯為"客觀"失效,即多個sentinel實例都認為master處于"SDOWN"狀態(tài),那么此時master將處于ODOWN,ODOWN可以簡單理解為master已經(jīng)被集群確定
為"不可用",將會開啟failover.
SDOWN適合于master和slave,但是ODOWN只會使用于master;當slave失效超過"down-after-milliseconds"后,那么所有sentinel實例都會將其標記為"SDOWN"岔帽。
1) SDOWN與ODOWN轉(zhuǎn)換過程:
每個sentinel實例在啟動后,都會和已知的slaves/master以及其他sentinels建立TCP連接,并周期性發(fā)送PING(默認為1秒)
在交互中,如果redis-server無法在"down-after-milliseconds"時間內(nèi)響應(yīng)或者響應(yīng)錯誤信息,都會被認為此redis-server處于SDOWN狀態(tài)。
如果SDOWN的server為master,那么此時sentinel實例將會向其他sentinel間歇性(一秒)發(fā)送"is-master-down-by-addr <ip> <port>"指令并獲取響應(yīng)信息,如果足夠多的
sentinel實例檢測到master處于SDOWN,那么此時當前sentinel實例標記master為ODOWN...其他sentinel實例做同樣的交互操作导绷。
配置項"sentinel monitor <mastername> <masterip> <masterport> <quorum>",如果檢測到master處于SDOWN狀態(tài)的slave個數(shù)達到<quorum>,那么此時此sentinel實例將會認為
master處于ODOWN犀勒。每個sentinel實例將會間歇性(10秒)向master和slaves發(fā)送"INFO"指令,如果master失效且沒有新master選出時,每1秒發(fā)送一次"INFO";"INFO"的主要目的就是
獲取并確認當前集群環(huán)境中slaves和master的存活情況。
經(jīng)過上述過程后,所有的sentinel對master失效達成一致后,開始failover.
2) Sentinel與slaves"自動發(fā)現(xiàn)"機制:
在sentinel的配置文件中(local-sentinel.conf),都指定了port,此port就是sentinel實例偵聽其他sentinel實例建立鏈接的端口.在集群穩(wěn)定后,最終會每個sentinel實例之間都
會建立一個tcp鏈接,此鏈接中發(fā)送"PING"以及類似于"is-master-down-by-addr"指令集,可用用來檢測其他sentinel實例的有效性以及"ODOWN"和"failover"過程中信息的交互.
在sentinel之間建立連接之前,sentinel將會盡力和配置文件中指定的master建立連接.sentinel與master的連接中的通信主要是基于pub/sub來發(fā)布和接收信息,發(fā)布的信息內(nèi)容包
括當前sentinel實例的偵聽端口:
+sentinel sentinel 127.0.0.1:26579 127.0.0.1 26579 ....
發(fā)布的主題名稱為"__sentinel__:hello";同時sentinel實例也是"訂閱"此主題,以獲得其他sentinel實例的信息.由此可見,環(huán)境首次構(gòu)建時,在默認master存活的情況下,所有的
sentinel實例可以通過pub/sub即可獲得所有的sentinel信息,此后每個sentinel實例即可以根據(jù)+sentinel信息中的"ip+port"和其他sentinel逐個建立tcp連接即可.不過需要提醒
的是,每個sentinel實例均會間歇性(5秒)向"__sentinel__:hello"主題中發(fā)布自己的ip+port,目的就是讓后續(xù)加入集群的sentinel實例也能或得到自己的信息。
根據(jù)上文,我們知道在master有效的情況下,即可通過"INFO"指令獲得當前master中已有的slave列表;此后任何slave加入集群,master都會向"主題中"發(fā)布"+slave 127.0.0.1:6579 ..",
那么所有的sentinel也將立即獲得slave信息,并和slave建立鏈接并通過PING檢測其存活性.
補充一下,每個sentinel實例都會保存其他sentinel實例的列表以及現(xiàn)存的master/slaves列表,各自的列表中不會有重復(fù)的信息(不可能出現(xiàn)多個tcp連接),對于sentinel將使用ip+port
做唯一性標記,
對于master/slaver將使用runid做唯一性標記,其中redis-server的runid在每次啟動時都不同.
3) Leader選舉:
其實在sentinels故障轉(zhuǎn)移中贾费，仍然需要一個"Leader"來調(diào)度整個過程：master的選舉以及slave的重配置和同步钦购。當集群中有多個sentinel實例時，如何選舉其中一個sentinel為leader呢褂萧？
在配置文件中"can-failover""quorum"參數(shù)押桃，以及"is-master-down-by-addr"指令配合來完成整個過程。
A) "can-failover"用來表明當前sentinel是否可以參與"failover"過程箱玷，如果為"YES"則表明它將有能力參與"Leader"的選舉怨规，否則它將作為"Observer"陌宿，observer參與leader選舉投票但
不能被選舉锡足；
B) "quorum"不僅用來控制master ODOWN狀態(tài)確認，同時還用來選舉leader時最小"贊同票"數(shù)壳坪；
C) "is-master-down-by-addr"舶得，它可以用來檢測"ip + port"的master是否已經(jīng)處于SDOWN狀態(tài)，不過此指令不僅能夠獲得master是否處于SDOWN爽蝴，同時它還額外的返回當前sentinel
本地"投票選舉"的Leader信息(runid);
每個sentinel實例都持有其他的sentinels信息沐批，在Leader選舉過程中(當為leader的sentinel實例失效時，有可能master server并沒失效蝎亚，注意分開理解)九孩，sentinel實例將從所有的
sentinels集合中去除"can-failover = no"和狀態(tài)為SDOWN的sentinels，在剩余的sentinels列表中按照runid按照"字典"順序排序后发框，取出runid最小的sentinel實例躺彬，并將它"投票選舉"
為Leader，并在其他sentinel發(fā)送的"is-master-down-by-addr"指令時將推選的runid追加到響應(yīng)中梅惯。每個sentinel實例都會檢測"is-master-down-by-addr"的響應(yīng)結(jié)果宪拥，如果"投票選舉"的
leader為自己，且狀態(tài)正常的sentinels實例中铣减，"贊同者"的自己的sentinel個數(shù)不小于(>=) 50% + 1,且不小與<quorum>她君，那么此sentinel就會認為選舉成功且leader為自己。
在sentinel.conf文件中葫哗，我們期望有足夠多的sentinel實例配置"can-failover yes"缔刹，這樣能夠確保當leader失效時，能夠選舉某個sentinel為leader劣针，以便進行failover校镐。如果leader無法產(chǎn)生，
比如較少的sentinels實例有效酿秸，那么failover過程將無法繼續(xù).
4) failover過程:
在Leader觸發(fā)failover之前灭翔，首先wait數(shù)秒(隨即0~5)，以便讓其他sentinel實例準備和調(diào)整(有可能多個leader??),如果一切正常，那么leader就需要開始將一個salve提升為master肝箱，此slave
必須為狀態(tài)良好(不能處于SDOWN/ODOWN狀態(tài))且權(quán)重值最低(redis.conf中)的哄褒，當master身份被確認后，開始failover
A）"+failover-triggered": Leader開始進行failover煌张，此后緊跟著"+failover-state-wait-start"呐赡，wait數(shù)秒。
B）"+failover-state-select-slave": Leader開始查找合適的slave
C）"+selected-slave": 已經(jīng)找到合適的slave
D） "+failover-state-sen-slaveof-noone": Leader向slave發(fā)送"slaveof no one"指令骏融，此時slave已經(jīng)完成角色轉(zhuǎn)換链嘀，此slave即為master
E） "+failover-state-wait-promotition": 等待其他sentinel確認slave
F）"+promoted-slave"：確認成功
G）"+failover-state-reconf-slaves": 開始對slaves進行reconfig操作。
H）"+slave-reconf-sent":向指定的slave發(fā)送"slaveof"指令档玻，告知此slave跟隨新的master
I）"+slave-reconf-inprog": 此slave正在執(zhí)行slaveof + SYNC過程怀泊，如過slave收到"+slave-reconf-sent"之后將會執(zhí)行slaveof操作。
J）"+slave-reconf-done": 此slave同步完成误趴，此后leader可以繼續(xù)下一個slave的reconfig操作霹琼。循環(huán)G）
K）"+failover-end": 故障轉(zhuǎn)移結(jié)束
L）"+switch-master"：故障轉(zhuǎn)移成功后，各個sentinel實例開始監(jiān)控新的master凉当。
二枣申、redis sentinel 主從切換(failover)的容災(zāi)環(huán)境部署記錄
redis主從復(fù)制簡單來說：
A）Redis的復(fù)制功能是支持多個數(shù)據(jù)庫之間的數(shù)據(jù)同步。一類是主數(shù)據(jù)庫（master）一類是從數(shù)據(jù)庫（slave）看杭，主數(shù)據(jù)庫可以進行讀寫操作忠藤，當發(fā)生寫操作的時候自動將數(shù)據(jù)同步到從數(shù)據(jù)庫，而從數(shù)據(jù)庫一般是只讀的楼雹，并接收主數(shù)據(jù)庫同步過來的數(shù)據(jù)模孩，一個主數(shù)據(jù)庫可以有多個從數(shù)據(jù)庫，而一個從數(shù)據(jù)庫只能有一個主數(shù)據(jù)庫烘豹。
B）通過redis的復(fù)制功能可以很好的實現(xiàn)數(shù)據(jù)庫的讀寫分離瓜贾，提高服務(wù)器的負載能力。主數(shù)據(jù)庫主要進行寫操作携悯，而從數(shù)據(jù)庫負責(zé)讀操作祭芦。
Redis主從復(fù)制流程簡圖
redis主從復(fù)制的大致過程：
1）當一個從數(shù)據(jù)庫啟動時，會向主數(shù)據(jù)庫發(fā)送sync命令憔鬼，
2）主數(shù)據(jù)庫接收到sync命令后會開始在后臺保存快照（執(zhí)行rdb操作）龟劲，并將保存期間接收到的命令緩存起來
3）當快照完成后，redis會將快照文件和所有緩存的命令發(fā)送給從數(shù)據(jù)庫轴或。
4）從數(shù)據(jù)庫收到后昌跌，會載入快照文件并執(zhí)行收到的緩存的命令。
注意：redis2.8之前的版本：當主從數(shù)據(jù)庫同步的時候從數(shù)據(jù)庫因為網(wǎng)絡(luò)原因斷開重連后會重新執(zhí)行上述操作照雁，不支持斷點續(xù)傳蚕愤。redis2.8之后支持斷點續(xù)傳。
0）Redis主從結(jié)構(gòu)支持一主多從+n個sentinel模式，信息如下：
192.168.10.202 redis-master redis（6379）萍诱、sentinel（26379）
192.168.10.203 redis-slave01 redis（6379）悬嗓、sentinel（26379）
192.168.10.205 redis-slave02 redis（6379）、sentinel（26379）
關(guān)閉三個節(jié)點機器的iptables和selinux（所有節(jié)點機器上都要操作）
[root@redis-master ~]# /etc/init.d/iptables stop
[root@redis-master ~]# vim /etc/sysconfig/selinux
......
SELINUX=disabled
[root@redis-master ~]# setenforce 0
[root@redis-master ~]# getenforce
Permissive
注意：本案例采用1主2從+3 sentinel的集群模式裕坊，所有從節(jié)點的配置都一樣包竹。
a）redis服務(wù)器上各自存在一個Sentinel，監(jiān)控本機redis的運行情況籍凝，并通知給閉路環(huán)上其它的redis節(jié)點周瞎；
b）當master發(fā)生異常（例如：宕機和斷電等）導(dǎo)致不可運行時，Sentinel將通知給其它節(jié)點饵蒂，而剩余節(jié)點上的Sentinel將重新選舉出新的master声诸，而原來的master重新恢復(fù)正常后，則一直扮演slave角色苹享；
c）規(guī)定整個架構(gòu)體系中双絮，master提供讀寫服務(wù)，而slave只提供讀取服務(wù)得问。
1）redis一鍵安裝（三個節(jié)點上都要操作）
[root@redis-master ~]# cd /usr/local/src/
[root@redis-master src]# vim install_redis.sh
#!/usr/bin/env bash
# It's Used to be install redis.
# Created on 2018/04/08 11:18.
# @author: wangshibo.
# Version: 1.0
function install_redis () {
#################################################################################################
cd /usr/local/src
if [ ! -f " redis-4.0.1.tar.gz" ]; then
wget http://download.redis.io/releases/redis-4.0.1.tar.gz
fi
cd /usr/local/src
tar -zxvf /usr/local/src/redis-4.0.1.tar.gz
cd redis-4.0.1
make PREFIX=/usr/local/redis install
mkdir -p /usr/local/redis/{etc,var}
rsync -avz redis.conf /usr/local/redis/etc/
sed -i 's@pidfile.*@pidfile /var/run/redis-server.pid@' /usr/local/redis/etc/redis.conf
sed -i "s@logfile.*@logfile /usr/local/redis/var/redis.log@" /usr/local/redis/etc/redis.conf
sed -i "s@^dir.*@dir /usr/local/redis/var@" /usr/local/redis/etc/redis.conf
sed -i 's/daemonize no/daemonize yes/g' /usr/local/redis/etc/redis.conf
sed -i 's/^# bind 127.0.0.1/bind 0.0.0.0/g' /usr/local/redis/etc/redis.conf
#################################################################################################
}
install_redis
[root@redis-master src]# chmod 755 install_redis.sh
[root@redis-master src]# sh -x install_redis.sh
2）redis啟停腳本（三個節(jié)點上都要操作）
[root@redis-master src]# vim /etc/init.d/redis-server
#!/bin/bash
#
# redis - this script starts and stops the redis-server daemon
#
# chkconfig: - 85 15
# description: Redis is a persistent key-value database
# processname: redis-server
# config: /usr/local/redis/etc/redis.conf
# config: /etc/sysconfig/redis
# pidfile: /usr/local/redis/var/redis-server.pid
# Source function library.
. /etc/rc.d/init.d/functions
# Source networking configuration.
. /etc/sysconfig/network
# Check that networking is up.
[ "$NETWORKING" = "no" ] && exit 0
redis="/usr/local/redis/bin/redis-server"
prog=$(basename $redis)
REDIS_CONF_FILE="/usr/local/redis/etc/redis.conf"
[ -f /etc/sysconfig/redis ] && . /etc/sysconfig/redis
lockfile=/var/lock/subsys/redis-server
start() {
[ -x $redis ] || exit 5
[ -f $REDIS_CONF_FILE ] || exit 6
echo -n $"Starting $prog: "
daemon $redis $REDIS_CONF_FILE
retval=$?
echo
[ $retval -eq 0 ] && touch $lockfile
return $retval
}
stop() {
echo -n $"Stopping $prog: "
killproc $prog
retval=$?
echo
[ $retval -eq 0 ] && rm -f $lockfile
return $retval
}
restart() {
stop
start
}
reload() {
echo -n $"Reloading $prog: "
killproc $redis -HUP
RETVAL=$?
echo
}
force_reload() {
restart
}
rh_status() {
status $prog
}
rh_status_q() {
rh_status >/dev/null 2>&1
}
case "$1" in
start)
rh_status_q && exit 0
$1
;;
stop)
rh_status_q || exit 0
$1
;;
restart)
$1
;;
reload)
rh_status_q || exit 7
$1
;;
force-reload)
force_reload
;;
status)
rh_status
;;
condrestart|try-restart)
rh_status_q || exit 0
;;
*)
echo $"Usage: $0 {start|stop|status|restart|condrestart|try-restart|reload|force-reload}"
exit 2
esac
執(zhí)行權(quán)限
[root@redis-master src]# chmod 755 /etc/init.d/redis-server
3）redis-sentinel啟停腳本示例（三個節(jié)點上都要操作）
[root@redis-master src]# vim /etc/init.d/redis-sentinel
#!/bin/bash
#
# redis-sentinel - this script starts and stops the redis-server sentinel daemon
#
# chkconfig: - 85 15
# description: Redis sentinel
# processname: redis-server
# config: /usr/local/redis/etc/sentinel.conf
# config: /etc/sysconfig/redis
# pidfile: /usr/local/redis/var/redis-sentinel.pid
# Source function library.
. /etc/rc.d/init.d/functions
# Source networking configuration.
. /etc/sysconfig/network
# Check that networking is up.
[ "$NETWORKING" = "no" ] && exit 0
redis="/usr/local/redis/bin/redis-sentinel"
prog=$(basename $redis)
REDIS_CONF_FILE="/usr/local/redis/etc/sentinel.conf"
[ -f /etc/sysconfig/redis ] && . /etc/sysconfig/redis
lockfile=/var/lock/subsys/redis-sentinel
start() {
[ -x $redis ] || exit 5
[ -f $REDIS_CONF_FILE ] || exit 6
echo -n $"Starting $prog: "
daemon $redis $REDIS_CONF_FILE --sentinel
retval=$?
echo
[ $retval -eq 0 ] && touch $lockfile
return $retval
}
stop() {
echo -n $"Stopping $prog: "
killproc $prog
retval=$?
echo
[ $retval -eq 0 ] && rm -f $lockfile
return $retval
}
restart() {
stop
start
}
reload() {
echo -n $"Reloading $prog: "
killproc $redis -HUP
RETVAL=$?
echo
}
force_reload() {
restart
}
rh_status() {
status $prog
}
rh_status_q() {
rh_status >/dev/null 2>&1
}
case "$1" in
start)
rh_status_q && exit 0
$1
;;
stop)
rh_status_q || exit 0
$1
;;
restart)
$1
;;
reload)
rh_status_q || exit 7
$1
;;
force-reload)
force_reload
;;
status)
rh_status
;;
condrestart|try-restart)
rh_status_q || exit 0
;;
*)
echo $"Usage: $0 {start|stop|status|restart|condrestart|try-restart|reload|force-reload}"
exit 2
esac
執(zhí)行權(quán)限：
[root@redis-master src]# chmod 755 /etc/init.d/redis-sentinel
4）配置redis.conf
a）編輯redis-master主節(jié)點的redis.conf文件
[root@redis-master src]# mkdir -p /usr/local/redis/data/redis
[root@redis-master src]# cp /usr/local/redis/etc/redis.conf /usr/local/redis/etc/redis.conf.bak
[root@redis-master src]# vim /usr/local/redis/etc/redis.conf
bind 0.0.0.0
daemonize yes
pidfile "/usr/local/redis/var/redis-server.pid"
port 6379
tcp-backlog 128
timeout 0
tcp-keepalive 0
loglevel notice
logfile "/usr/local/redis/var/redis-server.log"
databases 16
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
dir "/usr/local/redis/data/redis"
#masterauth "20180408" #master設(shè)置密碼保護，即slave連接master時的密碼
#requirepass "20180408" #設(shè)置Redis連接密碼软免，如果配置了連接密碼宫纬，客戶端在連接Redis時需要通過AUTH <password>命令提供密碼，默認關(guān)閉
slave-serve-stale-data yes
slave-read-only yes
repl-diskless-sync no
repl-diskless-sync-delay 5
repl-disable-tcp-nodelay no
slave-priority 100
appendonly yes #打開aof持久化
appendfilename "appendonly.aof"
appendfsync everysec # 每秒一次aof寫
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
latency-monitor-threshold 0
notify-keyspace-events ""
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-entries 512
list-max-ziplist-value 64
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
aof-rewrite-incremental-fsync yes
注意：
上面配置中masterauth和requirepass表示設(shè)置密碼保護膏萧，如果設(shè)置了密碼漓骚，則連接redis后需要執(zhí)行"auth 20180408"密碼后才能操作其他命令。這里我不設(shè)置密碼榛泛。
b）編輯redis-slave01和redis-slave02兩個從節(jié)點的redis.conf文件
[root@redis-slave01 src]# mkdir -p /usr/local/redis/data/redis
[root@redis-slave01 src]# cp /usr/local/redis/etc/redis.conf /usr/local/redis/etc/redis.conf.bak
[root@redis-slave01 src]# vim /usr/local/redis/etc/redis.conf
bind 0.0.0.0
daemonize yes
pidfile "/usr/local/redis/var/redis-server.pid"
port 6379
tcp-backlog 128
timeout 0
tcp-keepalive 0
loglevel notice
logfile "/usr/local/redis/var/redis-server.log"
databases 16
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
dir "/usr/local/redis/data/redis"
#masterauth "20180408"
#requirepass "20180408"
slaveof 192.168.10.202 6379 #相對主redis配置蝌蹂，多添加了此行
slave-serve-stale-data yes
slave-read-only yes #從節(jié)點只讀，不能寫入
repl-diskless-sync no
repl-diskless-sync-delay 5
repl-disable-tcp-nodelay no
slave-priority 100
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
latency-monitor-threshold 0
notify-keyspace-events ""
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-entries 512
list-max-ziplist-value 64
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
hz 10
aof-rewrite-incremental-fsync yes
5）配置sentinel.conf（這個默認沒有曹锨，需要自建）孤个。三個節(jié)點的配置一樣。
[root@redis-master src]# mkdir -p /usr/local/redis/data/sentinel
[root@redis-master src]# vim /usr/local/redis/etc/sentinel.conf
port 26379
pidfile "/usr/local/redis/var/redis-sentinel.pid"
dir "/usr/local/redis/data/sentinel"
daemonize yes
protected-mode no
logfile "/usr/local/redis/var/redis-sentinel.log"
sentinel monitor redisMaster 192.168.10.202 6379 2
sentinel down-after-milliseconds redisMaster 10000
sentinel parallel-syncs redisMaster 1
sentinel failover-timeout redisMaster 60000
6）啟動redis和sentinel（三個節(jié)點都要操作）
設(shè)置系統(tǒng)變量
[root@redis-slave02 src]# vim /etc/profile
.......
export PATH=$PATH:/usr/local/redis/bin
[root@redis-slave02 src]# source /etc/profile
啟動redis和sentinel
[root@redis-master src]# /etc/init.d/redis-server start
Starting redis-server: [ OK ]
[root@redis-master src]# /etc/init.d/redis-sentinel start
Starting redis-sentinel: [ OK ]
[root@redis-master src]# lsof -i:6379
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
redis-ser 2297 root 6u IPv4 7819726 0t0 TCP *:6379 (LISTEN)
redis-ser 2297 root 8u IPv4 7819778 0t0 TCP 192.168.10.202:6379->192.168.10.202:56226 (ESTABLISHED)
redis-ser 2297 root 9u IPv4 7819780 0t0 TCP 192.168.10.202:6379->192.168.10.202:56228 (ESTABLISHED)
redis-sen 2315 root 8u IPv4 7819777 0t0 TCP 192.168.10.202:56226->192.168.10.202:6379 (ESTABLISHED)
redis-sen 2315 root 9u IPv4 7819779 0t0 TCP 192.168.10.202:56228->192.168.10.202:6379 (ESTABLISHED)
[root@redis-master src]# lsof -i:26379
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
redis-sen 2315 root 6u IPv6 7819772 0t0 TCP *:26379 (LISTEN)
redis-sen 2315 root 7u IPv4 7819773 0t0 TCP *:26379 (LISTEN)
7）查看redis和sentinel信息
1）查看三個節(jié)點的redis的主從關(guān)系
[root@redis-master src]# redis-cli -h 192.168.10.202 -p 6379 INFO|grep role
role:master
[root@redis-master src]# redis-cli -h 192.168.10.203 -p 6379 INFO|grep role
role:slave
[root@redis-master src]# redis-cli -h 192.168.10.205 -p 6379 INFO|grep role
role:slave
從上面信息可以看出沛简，192.168.10.202是master齐鲤，192.168.10.203和192.168.10.205是slave
2）查看Master節(jié)點信息：
[root@redis-master src]# redis-cli -h 192.168.10.202 -p 6379 info Replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.10.203,port=6379,state=online,offset=61480,lag=0
slave1:ip=192.168.10.205,port=6379,state=online,offset=61480,lag=0
master_replid:96a1fd63d0ad9e7903851a82382e32d690667bcc
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:61626
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:61626
從上面信息看出，此時192.168.10.202的角色為master椒楣，有兩個slave（203和205）被連接成功.
此時打開master的sentinel.conf给郊，在末尾可看到如下自動寫入的內(nèi)容：
[root@redis-master src]# cat /usr/local/redis/etc/sentinel.conf
port 26379
pidfile "/usr/local/redis/var/redis-sentinel.pid"
dir "/usr/local/redis/data/sentinel"
daemonize yes
protected-mode no
logfile "/usr/local/redis/var/redis-sentinel.log"
sentinel myid c165761901b5ea3cd2d622bbf13f4c99eb73c1bc
sentinel monitor redisMaster 192.168.10.202 6379 2
sentinel down-after-milliseconds redisMaster 10000
sentinel failover-timeout redisMaster 60000
# Generated by CONFIG REWRITE
sentinel config-epoch redisMaster 0
sentinel leader-epoch redisMaster 0
sentinel known-slave redisMaster 192.168.10.203 6379
sentinel known-slave redisMaster 192.168.10.205 6379
sentinel known-sentinel redisMaster 192.168.10.205 26379 cc25d5f0e37803e888732d63deae3761c9f91e1d
sentinel known-sentinel redisMaster 192.168.10.203 26379 e1505ffc65f787871febfde2f27b762f70cddd71
sentinel current-epoch 0
[root@redis-master ~]# redis-cli -h 192.168.10.205 -p 26379 info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=redisMaster,status=ok,address=192.168.10.202:6379,slaves=2,sentinels=3
3）查看Slave節(jié)點信息：
先查看salve01節(jié)點信息
[root@redis-slave01 src]# redis-cli -h 192.168.10.203 -p 6379 info Replication
# Replication
role:slave
master_host:192.168.10.202
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:96744
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:96a1fd63d0ad9e7903851a82382e32d690667bcc
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:96744
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:96744
此時192.168.10.203的角色為slave，它們所屬的master為220捧灰。
此時打開slave的sentinel.conf淆九，在末尾可看到如下自動寫入的內(nèi)容：
[root@redis-slave01 src]# cat /usr/local/redis/etc/sentinel.conf
port 26379
pidfile "/usr/local/redis/var/redis-sentinel.pid"
dir "/usr/local/redis/data/sentinel"
daemonize yes
protected-mode no
logfile "/usr/local/redis/var/redis-sentinel.log"
sentinel myid e1505ffc65f787871febfde2f27b762f70cddd71
sentinel monitor redisMaster 192.168.10.202 6379 2
sentinel down-after-milliseconds redisMaster 10000
sentinel failover-timeout redisMaster 60000
# Generated by CONFIG REWRITE
sentinel config-epoch redisMaster 0
sentinel leader-epoch redisMaster 0
sentinel known-slave redisMaster 192.168.10.203 6379
sentinel known-slave redisMaster 192.168.10.205 6379
sentinel known-sentinel redisMaster 192.168.10.205 26379 cc25d5f0e37803e888732d63deae3761c9f91e1d
sentinel known-sentinel redisMaster 192.168.10.202 26379 c165761901b5ea3cd2d622bbf13f4c99eb73c1bc
sentinel current-epoch 0
[root@redis-slave01 ~]# redis-cli -h 192.168.10.203 -p 26379 info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=redisMaster,status=ok,address=192.168.10.202:6379,slaves=2,sentinels=3
同樣查看slave02節(jié)點的信息
[root@redis-slave02 src]# redis-cli -h 192.168.10.205 -p 6379 info Replication
# Replication
role:slave
master_host:192.168.10.202
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:99678
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:96a1fd63d0ad9e7903851a82382e32d690667bcc
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:99678
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:170
repl_backlog_histlen:99509
[root@redis-slave02 src]# cat /usr/local/redis/etc/sentinel.conf
port 26379
pidfile "/usr/local/redis/var/redis-sentinel.pid"
dir "/usr/local/redis/data/sentinel"
daemonize yes
protected-mode no
logfile "/usr/local/redis/var/redis-sentinel.log"
sentinel myid cc25d5f0e37803e888732d63deae3761c9f91e1d
sentinel monitor redisMaster 192.168.10.202 6379 2
sentinel down-after-milliseconds redisMaster 10000
sentinel failover-timeout redisMaster 60000
# Generated by CONFIG REWRITE
sentinel config-epoch redisMaster 0
sentinel leader-epoch redisMaster 0
sentinel known-slave redisMaster 192.168.10.205 6379
sentinel known-slave redisMaster 192.168.10.203 6379
sentinel known-sentinel redisMaster 192.168.10.203 26379 e1505ffc65f787871febfde2f27b762f70cddd71
sentinel known-sentinel redisMaster 192.168.10.202 26379 c165761901b5ea3cd2d622bbf13f4c99eb73c1bc
sentinel current-epoch 0
[root@redis-slave02 ~]# redis-cli -h 192.168.10.205 -p 26379 info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=redisMaster,status=ok,address=192.168.10.202:6379,slaves=2,sentinels=3
8）客戶端寫入測試數(shù)據(jù)
客戶端連接master節(jié)點，寫入一條數(shù)據(jù)
[root@redis-master src]# redis-cli -h 192.168.10.202 -p 6379
192.168.10.202:6379> set name kevin;
OK
192.168.10.202:6379> get name;
"kevin";
然后客戶端再連接任意slave節(jié)點，通過get獲取上面的那條數(shù)據(jù)
[root@redis-master src]# redis-cli -h 192.168.10.203 -p 6379
192.168.10.203:6379> get name
"kevin;"
192.168.10.203:6379> set name grace;
(error) READONLY You can't write against a read only slave.
192.168.10.203:6379>
[root@redis-master src]# redis-cli -h 192.168.10.205 -p 6379
192.168.10.205:6379> get name
"kevin;"
192.168.10.205:6379> set name grace;
(error) READONLY You can't write against a read only slave.
192.168.10.205:6379>
由上面測試信息可知炭庙，master節(jié)點可以寫入跪另，可以讀取煤搜；而slave節(jié)點默認只能讀取免绿，不能寫入！這就實現(xiàn)了主從復(fù)制擦盾，讀寫分離了嘲驾！
9）模擬故障（通過sentinel實現(xiàn)主從切換，sentinel也要部署多臺迹卢，即集群模式辽故，防止單臺sentinel掛掉情況）
1）關(guān)掉任意一個slave節(jié)點（比如關(guān)閉掉slave01節(jié)點），所有節(jié)點的sentinel都可以檢測到腐碱，出現(xiàn)如下示例信息：
[root@redis-master src]# redis-cli -h 192.168.10.203 -p 6379
192.168.10.203:6379> get name
"kevin;"
192.168.10.203:6379> set name grace;
(error) READONLY You can't write against a read only slave.
192.168.10.203:6379> shutdown
not connected>
說明：shutdown命令表示關(guān)閉redis
從上可看出203被sentinel檢測到已處于關(guān)閉狀態(tài)誊垢，此時再來查看剩余節(jié)點的主從信息，它們的角色不會發(fā)生變化症见，只是master上的connected_slaves變?yōu)榱?喂走。
[root@redis-master src]# redis-cli -h 192.168.10.202 -p 6379 info replication
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.10.205,port=6379,state=online,offset=219376,lag=1
master_replid:96a1fd63d0ad9e7903851a82382e32d690667bcc
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:219376
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:219376
查看sentinel日志（任意節(jié)點上查看），發(fā)現(xiàn)203節(jié)點已經(jīng)進入"+sdown"狀態(tài)
[root@redis-master src]# tail -f /usr/local/redis/var/redis-sentinel.log
2315:X 08 May 18:49:51.429 * Increased maximum number of open files to 10032 (it was originally set to 1024).
2315:X 08 May 18:49:51.431 * Running mode=sentinel, port=26379.
2315:X 08 May 18:49:51.431 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
2315:X 08 May 18:49:51.463 # Sentinel ID is c165761901b5ea3cd2d622bbf13f4c99eb73c1bc
2315:X 08 May 18:49:51.463 # +monitor master redisMaster 192.168.10.202 6379 quorum 2
2315:X 08 May 18:50:11.544 * +slave slave 192.168.10.203:6379 192.168.10.203 6379 @ redisMaster 192.168.10.202 6379
2315:X 08 May 18:50:11.574 * +slave slave 192.168.10.205:6379 192.168.10.205 6379 @ redisMaster 192.168.10.202 6379
2315:X 08 May 18:50:15.088 * +sentinel sentinel e1505ffc65f787871febfde2f27b762f70cddd71 192.168.10.203 26379 @ redisMaster 192.168.10.202 6379
2315:X 08 May 18:50:16.075 * +sentinel sentinel cc25d5f0e37803e888732d63deae3761c9f91e1d 192.168.10.205 26379 @ redisMaster 192.168.10.202 6379
2315:X 08 May 19:06:07.669 # +sdown slave 192.168.10.203:6379 192.168.10.203 6379 @ redisMaster 192.168.10.202 6379
然后重啟上面被關(guān)閉的slave節(jié)點（即192.168.10.203）谋作，所有節(jié)點的sentinel都可以檢測到芋肠，可看出221又被sentinel檢測到已處于可用狀態(tài)，此時再來查看節(jié)點的主從信息遵蚜，
它們的角色仍然不會發(fā)生變化帖池，master上的connected_slaves又變?yōu)榱?
[root@redis-slave01 src]# /etc/init.d/redis-server restart
Stopping redis-server: [FAILED]
Starting redis-server: [ OK ]
[root@redis-slave01 src]# /etc/init.d/redis-server restart
Stopping redis-server: [ OK ]
Starting redis-server: [ OK ]
[root@redis-master src]# redis-cli -h 192.168.10.202 -p 6379 info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.10.205,port=6379,state=online,offset=268216,lag=0
slave1:ip=192.168.10.203,port=6379,state=online,offset=268070,lag=1
master_replid:96a1fd63d0ad9e7903851a82382e32d690667bcc
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:268216
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:268216
查看sentinel日志（任意節(jié)點上查看），發(fā)現(xiàn)203節(jié)點已經(jīng)進入"-sdown"狀態(tài)
[root@redis-master src]# tail -f /usr/local/redis/var/redis-sentinel.log
2315:X 08 May 18:49:51.429 * Increased maximum number of open files to 10032 (it was originally set to 1024).
2315:X 08 May 18:49:51.431 * Running mode=sentinel, port=26379.
2315:X 08 May 18:49:51.431 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
2315:X 08 May 18:49:51.463 # Sentinel ID is c165761901b5ea3cd2d622bbf13f4c99eb73c1bc
2315:X 08 May 18:49:51.463 # +monitor master redisMaster 192.168.10.202 6379 quorum 2
2315:X 08 May 18:50:11.544 * +slave slave 192.168.10.203:6379 192.168.10.203 6379 @ redisMaster 192.168.10.202 6379
2315:X 08 May 18:50:11.574 * +slave slave 192.168.10.205:6379 192.168.10.205 6379 @ redisMaster 192.168.10.202 6379
2315:X 08 May 18:50:15.088 * +sentinel sentinel e1505ffc65f787871febfde2f27b762f70cddd71 192.168.10.203 26379 @ redisMaster 192.168.10.202 6379
2315:X 08 May 18:50:16.075 * +sentinel sentinel cc25d5f0e37803e888732d63deae3761c9f91e1d 192.168.10.205 26379 @ redisMaster 192.168.10.202 6379
2315:X 08 May 19:06:07.669 # +sdown slave 192.168.10.203:6379 192.168.10.203 6379 @ redisMaster 192.168.10.202 6379
2315:X 08 May 19:10:14.965 * +reboot slave 192.168.10.203:6379 192.168.10.203 6379 @ redisMaster 192.168.10.202 6379
2315:X 08 May 19:10:15.020 # -sdown slave 192.168.10.203:6379 192.168.10.203 6379 @ redisMaster 192.168.10.202 6379
=======================================================================================================
2）關(guān)掉master節(jié)點（即192.168.10.202）吭净，待所有節(jié)點的sentinel都檢測到后（稍等一會睡汹，2-3秒鐘時間），再來查看兩個Slave節(jié)點的主從信息寂殉，發(fā)現(xiàn)其中一個節(jié)點的角色通過選舉后會成為
master節(jié)點了囚巴！
[root@redis-master src]# redis-cli -h 192.168.10.202 -p 6379
192.168.10.202:6379> shutdown
not connected>
查看sentinel日志（任意節(jié)點上查看），發(fā)現(xiàn)202節(jié)點已經(jīng)進入"+sdown"狀態(tài)
[root@redis-master src]# tail -f /usr/local/redis/var/redis-sentinel.log
2315:X 08 May 19:17:03.722 # +failover-state-reconf-slaves master redisMaster 192.168.10.202 6379
2315:X 08 May 19:17:03.760 * +slave-reconf-sent slave 192.168.10.203:6379 192.168.10.203 6379 @ redisMaster 192.168.10.202 6379
2315:X 08 May 19:17:04.015 * +slave-reconf-inprog slave 192.168.10.203:6379 192.168.10.203 6379 @ redisMaster 192.168.10.202 6379
2315:X 08 May 19:17:04.459 # -odown master redisMaster 192.168.10.202 6379
2315:X 08 May 19:17:05.047 * +slave-reconf-done slave 192.168.10.203:6379 192.168.10.203 6379 @ redisMaster 192.168.10.202 6379
2315:X 08 May 19:17:05.131 # +failover-end master redisMaster 192.168.10.202 6379
2315:X 08 May 19:17:05.131 # +switch-master redisMaster 192.168.10.202 6379 192.168.10.205 6379
2315:X 08 May 19:17:05.131 * +slave slave 192.168.10.203:6379 192.168.10.203 6379 @ redisMaster 192.168.10.205 6379
2315:X 08 May 19:17:05.131 * +slave slave 192.168.10.202:6379 192.168.10.202 6379 @ redisMaster 192.168.10.205 6379
2315:X 08 May 19:17:15.170 # +sdown slave 192.168.10.202:6379 192.168.10.202 6379 @ redisMaster 192.168.10.205 6379
[root@redis-slave01 src]# redis-cli -h 192.168.10.203 -p 6379 INFO|grep role
role:slave
[root@redis-slave01 src]# redis-cli -h 192.168.10.205 -p 6379 INFO|grep role
role:master
[root@redis-slave01 src]# redis-cli -h 192.168.10.205 -p 6379 info replication
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.10.203,port=6379,state=online,offset=348860,lag=1
master_replid:a51f87958cea0b1e8fe2c83542ca6cebace53bf7
master_replid2:96a1fd63d0ad9e7903851a82382e32d690667bcc
master_repl_offset:349152
second_repl_offset:342824
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:170
repl_backlog_histlen:348983
[root@redis-slave01 src]# redis-cli -h 192.168.10.203 -p 6379 info replication
# Replication
role:slave
master_host:192.168.10.205
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:347546
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:a51f87958cea0b1e8fe2c83542ca6cebace53bf7
master_replid2:96a1fd63d0ad9e7903851a82382e32d690667bcc
master_repl_offset:347546
second_repl_offset:342824
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:283207
repl_backlog_histlen:64340
由上可知不撑，當master節(jié)點（即192.168.10.202）的redis關(guān)閉后文兢，slave02節(jié)點（即192.168.10.205）變成了新的master節(jié)點，而slave01（即192.168.10.203）成為
了slave02的從節(jié)點焕檬！
192.168.10.205節(jié)點此時被選舉為master姆坚，此時打開的205節(jié)點的redis.conf文件，slaveof配置項已被自動刪除了实愚。
而203從節(jié)點的redis.conf文件中slaveof配置項的值被自動修改為192.168.10.205 6379兼呵。
[root@redis-slave02 src]# cat /usr/local/redis/etc/redis.conf|grep slaveof
[root@redis-slave01 src]# cat /usr/local/redis/etc/redis.conf|grep slaveof
slaveof 192.168.10.205 6379
在這個新master上（即192.168.10.205）執(zhí)行諸如set這樣的寫入操作將被成功執(zhí)行
[root@redis-slave01 src]# redis-cli -h 192.168.10.205 -p 6379
192.168.10.205:6379> set name beijing;
OK
[root@redis-master src]# redis-cli -h 192.168.10.203 -p 6379
192.168.10.203:6379> get name
"beijing;"
192.168.10.203:6379> set name tianjin;
(error) READONLY You can't write against a read only slave.
192.168.10.203:6379>
重啟192.168.10.202節(jié)點的redis兔辅，待所有節(jié)點的sentinel都檢測到后，再來查看所有節(jié)點的主從信息击喂，此時192.168.10.205節(jié)點的master角色不會被重新?lián)屨迹?而192.168.10.202節(jié)點的角色會從原來的master變?yōu)榱藄lave维苔。
[root@redis-master src]# /etc/init.d/redis-server restart
Stopping redis-server: [FAILED]
Starting redis-server: [ OK ]
[root@redis-master src]# /etc/init.d/redis-server restart
Stopping redis-server: [ OK ]
Starting redis-server: [ OK ]
[root@redis-master src]# redis-cli -h 192.168.10.202 -p 6379 INFO|grep role
role:slave
[root@redis-master src]# redis-cli -h 192.168.10.203 -p 6379 INFO|grep role
role:slave
[root@redis-master src]# redis-cli -h 192.168.10.205 -p 6379 INFO|grep role
role:master
[root@redis-master src]# redis-cli -h 192.168.10.205 -p 6379 info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.10.203,port=6379,state=online,offset=545410,lag=1
slave1:ip=192.168.10.202,port=6379,state=online,offset=545410,lag=1
master_replid:a51f87958cea0b1e8fe2c83542ca6cebace53bf7
master_replid2:96a1fd63d0ad9e7903851a82382e32d690667bcc
master_repl_offset:545556
second_repl_offset:342824
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:170
repl_backlog_histlen:545387
[root@redis-master src]# redis-cli -h 192.168.10.202 -p 6379
192.168.10.202:6379> get name
"beijing;"
此時登錄192.168.10.202節(jié)點的redis，執(zhí)行"get name"得到的值為beijing懂昂，而不是原來的kevin介时，因為192.168.10.202節(jié)點的redis重啟后會自動從新的master中同步
數(shù)據(jù)。此時打開192.168.10.202節(jié)點的redis.conf文件凌彬，會在末尾找到如下信息：
[root@redis-master src]# cat /usr/local/redis/etc/redis.conf|grep slaveof
slaveof 192.168.10.205 6379
到此沸柔，已經(jīng)驗證出了redis sentinel可以自行實現(xiàn)主從的故障切換了！
10）客戶端如何連接redis sentinel铲敛？
客戶端配置連接的是sentinel信息褐澎，比如連接sentinel.conf文件中定義的master名稱。在sentinel監(jiān)聽時伐蒋，當master節(jié)點掛了工三，它會在slave節(jié)點中自動選舉出新
的master節(jié)點，而當掛了的老master節(jié)點重新恢復(fù)后就會成為新的slave節(jié)點先鱼。對于客戶端來說俭正，redis主從切換后它不需要修改連接配置。
下面列出幾個客戶端連接redis sentinel的例子
1）java客戶端在jedis中使用redis sentinel哨兵方式連接
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans">
<bean id="jedisPoolConfig" class="redis.clients.jedis.JedisPoolConfig">
<property name="maxTotal" value="1000"/>
<property name="maxIdle" value="10"/>
<property name="minIdle" value="1"/>
<property name="maxWaitMillis" value="30000"/>
<property name="testOnBorrow" value="true"/>
<property name="testOnReturn" value="true"/>
<property name="testWhileIdle" value="true"/>
</bean>
<bean id="cacheService" class="sentinel.CacheServiceImpl" destroy-method="destroy">
<property name="jedisSentinlePool">
<bean class="redis.clients.jedis.JedisSentinelPool">
<constructor-arg index="0" value="mymaster" />
<constructor-arg index="1">
<set>
<value>192.168.10.202:26379</value>
<value>192.168.10.203:26379</value>
<value>192.168.10.205:26379</value>
</set>
</constructor-arg>
<constructor-arg index="2" ref="jedisPoolConfig" />
</bean>
</property>
</bean>
</beans>
2）python連接redis sentinel集群（需要安裝python redis客戶端型型，即執(zhí)行"pip install redis"）
#!/usr/bin/env python
# -*- coding:utf-8 -*-
import redis
from redis.sentinel import Sentinel
# 連接哨兵服務(wù)器(主機名也可以用域名)
sentinel = Sentinel([('192.168.10.202', 26379),
('192.168.10.203', 26379),
('192.168.10.205', 26379)
],
socket_timeout=0.5)
# 獲取主服務(wù)器地址
master = sentinel.discover_master('mymaster')
print(master)
# 輸出：('192.168.10.202', 26379)
# 獲取從服務(wù)器地址
slave = sentinel.discover_slaves('mymaster')
print(slave)
# 輸出：[('192.168.10.203', 26379), ('192.168.10.205', 26379), ('172.31.0.5', 26379)]
# 獲取主服務(wù)器進行寫入
master = sentinel.master_for('mymaster', socket_timeout=0.5, password='redis_auth_pass', db=15)
w_ret = master.set('foo', 'bar')
# 輸出：True
# # 獲取從服務(wù)器進行讀榷紊蟆（默認是round-roubin）
slave = sentinel.slave_for('mymaster', socket_timeout=0.5, password='redis_auth_pass', db=15)
r_ret = slave.get('foo')
print(r_ret)
# # 輸出：bar
3）Java客戶端連接Redis（單sentinel）.
下面例子中好的redisMaster和20180408是在sentinel.conf中定義的master名稱和連接密碼
package com.hiifit.cloudplatform.gaia.test;
import java.util.HashSet;
import java.util.Set;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisSentinelPool;
public class RedisSentinelTest {
@SuppressWarnings("deprecation")
public static void main(String[] args) {
Set<String> sentinels = new HashSet<String>();
String hostAndPort1 = "192.168.10.205:26379";
sentinels.add(hostAndPort1);
String clusterName = "redisMaster";
String password = "20180408";
JedisSentinelPool redisSentinelJedisPool = new JedisSentinelPool(clusterName,sentinels,password);
Jedis jedis = null;
try {
jedis = redisSentinelJedisPool.getResource();
jedis.set("key", "value");
} catch (Exception e) {
e.printStackTrace();
} finally {
redisSentinelJedisPool.returnBrokenResource(jedis);
}
redisSentinelJedisPool.close();
}
}
