單機缺點及解決方案
單機問題：機器故障數據丟失、容量瓶頸。QPS瓶頸
需要集羣的原因：
- 併發量OPS的需求。要超過10w/s。
- 數據量“大數據”，機器只能存256G，但是需要存500G
3．集羣可以備份數據
Redis不能支撐高併發的瓶頸--單機
單機的redis幾乎不太可能說QPS(併發)超過10萬+，除非特殊情況，如機器性能特別好，配置特別高，物理機，維護做的特別好，而且整體的操作不是太複雜
Redis三種策略：
- 主從複製 ：
- 哨兵:哨兵機制爲了解決主從複製的缺點的
- 集羣:
選型：
單機：如果數據量很少，主要是承載高併發高性能的場景，如緩存一般就幾個G，單機足夠
主從Replication：一個mater，多個slave，要幾個slave跟要求的讀吞吐量有關係，然後搭建一個sentinal集羣，去保證redis主從架構的高可用性，就可以了
集羣redis cluster：主要是針對海量數據+高併發+高可用的場景，海量數據，如果數據量很大，建議用redis cluster
主從複製(Redis master slave replication)
主從複製：一主多從，主節點負責寫數據，從節點負責讀數據，主節點定期把數據同步到從節點保證數據的一致性
容易水平擴展，只需要增加redis slave就可以了
對主進行了數據備份。對主進行了分流，讀操作轉移到slave中（讀寫分離和容災恢復）
redis主從架構 -> 讀寫分離架構 -> 可支持水平擴展的讀高併發架構
數據同步：
Redis在master是非阻塞模式，即在slave執行數據同步時，master可接受客戶端請求，並不影響同步數據一致性，
在slave端是阻塞模式的，slave在同步master數據時，並不能夠響應客戶端的查詢
Redis的master/slave模式下，master提供數據讀寫服務，而slave只提供讀服務
特點：
1.master可配置多個slave；一個slave只能有一個master，slave可連接其他slave形成圖狀結構。數據流向是單向的，從master到salve
2. redis採用異步方式複製數據到slave節點，redis 2.8開始，slave node會週期性地確認自己每次複製的數據量。
Master：複製時不會阻塞。當一或多個slave與master進行初次同步數據時，master可繼續處理client發來的請求；
Slave：在初次同步數據時則會阻塞不能處理client的請求. 在做複製時，不會阻塞對自己的查詢操作，會用舊的數據集來提供服務; 但是複製完成時需刪除舊數據集，加載新數據集，這時就會暫停對外服務
3. 主從複製可用來提高系統的可伸縮性,可以用多個slave 專門用於client的讀請求，（數據副本、擴展讀性能（讀寫分離））
如sort操作可用slave來處理。也可用來做簡單的數據冗餘
4．slave node主要用來進行橫向擴容，做讀寫分離，擴容slave node可提高讀的吞吐量
過程：
1、當設置好slave服務器後，slave會建立和master的連接，然後發送sync命令。
2無論第一次同步建立連接還是連接斷開後重新連接，master都會啓動一個後臺進程，將數據庫快照保存到文件中，同時master主進程會開始收集新的寫命令並緩存起來。
3後臺進程完成寫文件後，master就發送文件給slave，slave將文件保存到磁盤上，然後加載到內存恢復數據庫快照到slave上。
4接着master就會把緩存的命令轉發給slave。後續master收到的寫命令都會通過開始建立的連接發送給slave。
注：
從master到slave的同步數據的命令和從 client發送的命令使用相同的協議格式。當master和slave的連接斷開時slave可自動重新建立連接。如果master同時收到多個 slave發來的同步連接命令，只會使用啓動一個進程來寫數據庫鏡像，然後發送給所有slave。(通過網絡傳輸的方式發個slave)
當啓動一個slave node的時候，它會發送一個PSYNC命令給master node
如果這是slave node重新連接master node，那麼master node僅僅會複製給slave部分缺少的數據;
否則如果是slave node第一次連接master node，那麼會觸發一次full resynchronization
開始full resynchronization的時候，master會啓動一個後臺線程，開始生成一份RDB快照文件，同時還會將從客戶端收到的所有寫命令緩存在內存中。RDB文件生成完畢之後，master會將這個RDB發送給slave，slave會先寫入本地磁盤，然後再從本地磁盤加載到內存中。然後master會將內存中緩存的寫命令異步發送給slave，slave也會同步這些數據。
slave node如果跟master node有網絡故障，斷開了連接，會自動重連。master如果發現有多個slave node都來重新連接，僅僅會啓動一個rdb save操作，用一份數據服務所有slave node。
複製的完整流程
（1）slave node啓動，僅僅保存master node的信息，包括master node的host和ip，但是複製流程沒開始
master host和ip是從redis.conf裏面的slaveof配置的
（2）slave node內部有個定時任務，每秒檢查是否有新的master node要連接和複製，如果發現，就跟master node建立socket網絡連接
（3）slave node發送ping命令給master node
（4）口令認證，如果master設置了requirepass，那麼salve node必須發送masterauth的口令過去進行認證
（5）master node第一次執行全量複製，將所有數據發給slave node
（6）master node後續持續將寫命令，異步複製給slave node
數據同步相關的核心機制
指第一次slave連接msater的時候，執行的全量複製，那個過程裏面一些細節的機制
（1）master和slave都會維護一個offset
master會在自身不斷累加offset，slave也會在自身不斷累加offset
slave每秒都會上報自己的offset給master，同時master會保存每個slave的offset
這個倒不是說特定就用在全量複製的，主要是master和slave都要知道各自的數據的offset，才能知道互相之間的數據不一致的情況
（2）backlog
master node有一個backlog，默認1MB大小
master node給slave node複製數據時，也會將數據在backlog中同步寫一份
backlog主要是用來做全量複製中斷候的增量複製的
（3）master run id
info server，可以看到master run id
如果根據host+ip定位master node，是不靠譜的，如果master node重啓或者數據出現了變化，那麼slave node應該根據不同的run id區分，run id不同就做全量複製
如果需要不更改run id重啓redis，可以使用redis-cli debug reload命令
連接時會創建一個標識，當run_id發生變化時，意味着需要同步
（4）psync
從節點使用psync從master node進行復制，psync runid offset
master node會根據自身的情況返回響應信息，可能是FULLRESYNC runid offset觸發全量複製，可能是CONTINUE觸發增量複製
無磁盤化複製
master在內存中直接創建rdb，然後發送給slave，不會在自己本地落地磁盤了
repl-diskless-sync
repl-diskless-sync-delay，等待一定時長再開始複製，因爲要等更多slave重新連接過來
過期key處理
slave不會過期key，只會等待master過期key。如果master過期了一個key，或者通過LRU淘汰了一個key，那麼會模擬一條del命令發送給slave
斷點續傳：
從redis 2.8開始，就支持主從複製的斷點續傳，如果主從複製過程中，網絡連接斷掉了，那麼可以接着上次複製的地方，繼續複製下去，而不是從頭開始複製一份
master node會在內存中常見一個backlog，master和slave都會保存一個replica offset還有一個master id，offset就是保存在backlog中的。如果master和slave網絡連接斷掉了，slave會讓master從上次的replica offset開始繼續複製
但是如果沒有找到對應的offset，那麼就會執行一次resynchronization
缺點：
主節點宕機後，就不可寫了。系統崩潰。可以使用哨兵機制選舉出新的master
實現主從複製的兩種方式：
1.通過slaveof命令
主從複製：
取消複製：
2.配置文件配置主從
修改配置的方式：
slaveof ip port
slave-read-only yes
1)主節點配置：
daemoize yes
pidfile /var/run/redis-6379.pid
logfile “6379.log”
#save 900 1
#save 300 10
#save 60 10000
dbfilename dump-6379.rdb
dir /opt/redis/data
2)從節點配置：
slaveof 192.168.1.1 6379 #指定master的ip和端口
客戶端查看信息：info replication
複製過程：
3.兩種方式的比較
|
方式 |
命令 |
配置 |
|
優點 |
無需重啓 |
統一配置 |
|
缺點 |
不便於管理 |
需要重啓 |
master持久化對主從架構的安全保障的意義
可在master禁用數據持久化，只需註釋掉master 配置文件中的所有save配置，然後只在slave上配置數據持久化。（只在slave中做持久化，但這樣做容易丟數據）
如果採用主從架構，建議必須開啓master node的持久化！
不建議用slave node作爲master node的數據熱備，因爲如果關掉master的持久化，可能在master宕機重啓的時候數據是空的，然後可能一經過複製，salve node數據也丟了
master -> RDB和AOF都關閉了 -> 全部在內存中
master宕機，重啓，沒有本地數據可恢復，會直接認爲自己數據是空的。master就會將空的數據集同步到slave上去，所有slave的數據全部清空。100%的數據丟失
總結：master節點，必須要使用持久化機制
第二個，master的各種備份方案，要不要做，萬一本地所有文件丟失；從備份中挑選一份rdb去恢復master; 這樣才能確保master啓動的時候，是有數據的
即使採用了後續講解的高可用機制，slave node可自動接管master node，但是也可能sentinal還沒有檢測到master failure，master node就自動重啓了，還是可能導致上面的所有slave node數據清空故障
全量複製
（1）master執行bgsave，在本地生成一份rdb快照文件
（2）master node將rdb快照文件發送給salve node，如果rdb複製時間超過60秒（repl-timeout），那麼slave node就會認爲複製失敗，可以適當調節大這個參數
（3）對於千兆網卡的機器，一般每秒傳輸100MB，6G文件，很可能超過60s
（4）master node在生成rdb時，會將所有新的寫命令緩存在內存中，在salve node保存了rdb之後，再將新的寫命令複製給salve node
（5）client-output-buffer-limit slave 256MB 64MB 60，如果在複製期間，內存緩衝區持續消耗超過64MB，或一次性超過256MB，那麼停止複製，複製失敗
（6）slave node接收到rdb之後，清空自己的舊數據，然後重新加載rdb到自己的內存中，同時基於舊的數據版本對外提供服務
（7）如果slave node開啓了AOF，那麼會立即執行BGREWRITEAOF，重寫AOF
rdb生成、rdb通過網絡拷貝、slave舊數據的清理、slave aof rewrite，很耗費時間
如果複製的數據量在4G~6G之間，那麼很可能全量複製時間消耗到1分半到2分鐘
全量複製的開銷大：
11、bgsave時間
2、RDB網絡
增量複製（部分複製）
（1）如果全量複製過程中，master-slave網絡連接斷掉，那麼salve重新連接master時，會觸發增量複製
（2）master直接從自己的backlog中獲取部分丟失的數據，發送給slave node，默認backlog是1MB
（3）msater就是根據slave發送的psync中的offset來從backlog中獲取數據的
heartbeat
主從節點互相都會發送heartbeat信息
master默認每隔10秒發送一次heartbeat，salve node每隔1秒發送一個heartbeat
異步複製
master每次接收到寫命令之後，現在內部寫入數據，然後異步發送給slave node
開發與運維中的問題
1.讀寫分離：讀流量分攤到從節點
可能遇到的問題：
複製數據延遲。數據一致性問題。
讀到過期數據。
從節點故障
2.主從配置不一致：
1、
小的觸發了淘汰機制
3.規避全量複製
4.規避複製風暴
哨兵機制（Sentinel）
哨兵機制是爲了解決主從複製的缺點的：
主從複製高可能問題：
1、如果主節點出現問題，需手工解決問題，也就是重啓master或手工選擇一個slave，使用slaveof no one命令或slaveof new master命令選出主和從。需要單獨寫腳本處理。問題是如何判斷節點故障，如何將命令發送給節點
2、寫能力和存儲能力受限，寫只在一個節點
sentinal哨兵： redis集羣架構中重要的組件，主要功能如下
（1）集羣監控，負責監控redis master和slave進程是否正常工作
（2）消息通知，如果某個redis實例有故障，那麼哨兵負責發送消息作爲報警通知給管理員
（3）故障轉移，如果master node掛掉了，會自動轉移到slave node上
（4）配置中心，如果故障轉移發生了，通知client客戶端新的master地址
哨兵本身也是分佈式的，作爲一個哨兵集羣去運行，互相協同工作
（1）故障轉移時，判斷一個master node是宕機了，需要大部分的哨兵都同意才行，涉及分佈式選舉的問題
（2）即使部分哨兵節點掛掉了，哨兵集羣還能正常工作，如果只有一個哨兵，不合理。
目前採用sentinal 2版本，sentinal 2相對sentinal 1主要是讓故障轉移的機制和算法變得更加健壯和簡單
主節點宕機後故障轉移過程：
多個sentinel發現並確認master有問題
選舉出一個sentinel作爲領導
選舉出一個slave作爲master
通知其他slave成爲新的master的slave
通知客戶端主從變化
等待老的master復活成爲新的master的slave
哨兵的核心知識
（1）哨兵至少需要3個實例，來保證自己的健壯性
（2）哨兵 + redis主從的部署架構，是不會保證數據零丟失的，只能保證redis集羣的高可用性
僅2節點的redis哨兵集羣無法正常工作：
哨兵集羣必須部署2個以上節點
如果哨兵集羣僅僅部署了個2個哨兵實例，quorum=1
+----+ +----+
| M1 |---------| R1 |
| S1 | | S2 |
+----+ +----+
Configuration: quorum = 1
master宕機，s1和s2中只要有1個哨兵認爲master宕機就可以還行切換，同時s1和s2中會選舉出一個哨兵來執行故障轉移
這時，需要majority，也就是大多數哨兵都是運行的，2個哨兵的majority就是2（2的majority=2，3的majority=2，5的majority=3，4的majority=2），2個哨兵都運行着，就可以允許執行故障轉移
如果整個M1和S1運行的機器宕機了，哨兵只有1個，沒有majority來允許執行故障轉移，雖然還有一個R1，但故障轉移不會執行。所以兩個節點的哨兵無法正常工作
經典的3節點哨兵集羣
+----+
| M1 |
| S1 |
+----+
|
+----+ | +----+
| R2 |----+----| R3 |
| S2 | | S3 |
+----+ +----+
Configuration: quorum = 2，majority
若M1所在機器宕機，3個哨兵還剩2個，S2和S3可一致認爲master宕機，然後選出一個來執行故障轉移
3個哨兵的majority是2，有2個哨兵運行着，就可以允許執行故障轉移
哨兵主備切換的數據丟失問題及解決方案：
redis哨兵主備切換的數據丟失問題：異步複製、集羣腦裂
1、兩種數據丟失的情況
主備切換的過程，可能導致數據丟失
1）異步複製導致的數據丟失
因master -> slave的複製是異步的，所以可能master有部分數據在master內存中還沒複製到slave，master就宕機了，此時這些部分數據丟失
2）集羣腦裂導致的數據丟失
腦裂，即某個master所在機器突然脫離了正常的網絡，跟其他slave機器不能連接，但是實際上master還運行着
此時哨兵可能就會認爲master宕機了，然後開啓選舉，將其他slave切換成了master
這時，集羣裏有兩個master，也就是所謂的腦裂
此時雖然某個slave被切換成了master，但是可能client還沒來得及切換到新的master，還繼續寫向舊master的數據可能也丟失了
因此舊master再次恢復網絡時，會被作爲一個slave掛到新的master上去，自己的數據會清空，重新從新的master複製數據
2、解決異步複製和腦裂導致的數據丟失
min-slaves-to-write 1
min-slaves-max-lag 10
要求至少有1個slave，數據複製和同步的延遲不能超過10秒
如果說一旦所有的slave，數據複製和同步的延遲都超過10秒鐘，這時，master就不會再接收任何請求
上面兩個配置可以減少異步複製和腦裂導致的數據丟失
1）減少異步複製的數據丟失
有了min-slaves-max-lag配置，可確保一旦slave複製數據和ack延時太長，就認爲可能master宕機後損失的數據太多了。
這樣可以把master宕機時由於部分數據未同步到slave導致的數據丟失降低的可控範圍內
降低損失，就是損失10s的數據。禁止客戶端向master寫入。等待slave同步完成。客戶端被拒絕後，將採用服務降級的方案，如kafka。保存數據。這一點需要客戶端自己編寫代碼實現。
2）減少腦裂的數據丟失
如果一個master出現了腦裂，跟其他slave丟了連接，那麼上面兩個配置可以確保說，如果不能繼續給指定數量的slave發送數據，而且slave超過10秒沒有給自己ack消息，那麼就直接拒絕客戶端的寫請求
這樣腦裂後的舊master就不會接受client的新數據，也就避免了數據丟失
上面的配置就確保了，如果跟任何一個slave丟了連接，在10秒後發現沒有slave給自己ack，那麼就拒絕新的寫請求
因此在腦裂場景下，最多就丟失10秒的數據
redis哨兵的多個核心底層原理的深入解析（包含slave選舉算法）
1、sdown和odown轉換機制
sdown和odown兩種失敗狀態
sdown是主觀宕機：一個哨兵如果自己覺得一個master宕機了
odown是客觀宕機：quorum數量的哨兵都覺得一個master宕機了
sdown達成條件簡單：如果一個哨兵ping一個master，超過is-master-down-after-milliseconds指定的毫秒數，就主觀認爲master宕機
sdown到odown轉換的條件很簡單：如果一個哨兵在指定時間內，收到quorum指定數量的其他哨兵也認爲那個master是sdown了，那麼就認爲是odown了，客觀認爲master宕機
2、哨兵集羣自動發現機制
哨兵互相之間的發現，是通過redis的pub/sub系統實現的，
每個哨兵都會往__sentinel__:hello這個channel裏發送一個消息，這時所有其他哨兵都可消費到這個消息，並感知到其他哨兵的存在
每隔兩秒鐘，每個哨兵都會往自己監控的某個master+slaves對應的__sentinel__:hello channel裏發送一個消息，內容是自己的host、ip和runid還有對這個master的監控配置
每個哨兵也會去監聽自己監控的每個master+slaves對應的__sentinel__:hello channel，然後去感知到同樣在監聽這個master+slaves的其他哨兵的存在
每個哨兵還會跟其他哨兵交換對master的監控配置，互相進行監控配置的同步
3、slave配置的自動糾正
哨兵會負責自動糾正slave的一些配置，
如slave如果要成爲潛在的master候選人，哨兵會確保slave在複製現有master的數據;
如slave連接到一個錯誤的master上，如故障轉移之後，哨兵會確保它們連接到正確的master上。
如一個哨兵讓slave變成了master，哨兵會讓其他slave修改配置，連接到新的master。
4、slave->master選舉算法
如果一個master被認爲odown，且majority哨兵都允許了主備切換，那麼某個哨兵就會執行主備切換操作，此時首先要選舉一個slave來
選舉考慮。會考慮slave的一些信息：
（1）跟master斷開連接的時長
如果一個slave跟master斷開連接超過down-after-milliseconds的10倍，外加master宕機的時長，slave就被認爲不適合選舉爲master
(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state
（2）slave優先級：
（3）複製offset
（4）run id
判斷斷開時長後，對slave進行排序，然後根據以下順序判斷：
1）按slave優先級進行排序，slave priority越低，優先級越高（slave priority可以進行配置的）
2）如果slave priority相同，就看replica offset，哪個slave複製了越多的數據，offset越靠後，優先級就越高
3）如果上面兩個條件都相同，就選擇一個run id比較小的那個slave
5、quorum和majority
每次一個哨兵要做主備切換，先要quorum數量的哨兵認爲odown，然後選舉一個哨兵來做切換，這個哨兵還要得到majority哨兵的授權，才能正式執行切換。
如果quorum < majority，如5個哨兵，majority是3，quorum設置爲2，要3個哨兵授權纔可執行切換
如果quorum >= majority，必須quorum數量的哨兵都授權，如5個哨兵，quorum是5，必須5個哨兵都同意授權，才能執行切換
quorum解釋如下：
（1）至少多少個哨兵要一致同意，master進程掛掉，或slave進程掛掉了，或者要啓動一個故障轉移操作
（2）quorum是用來識別故障的，真正執行故障轉移的時候，還要在哨兵集羣執行選舉，選舉一個哨兵進程出來執行故障轉移操作
（3）假設有5個哨兵，quorum設置了2，那麼如果5個哨兵中的2個都認爲master掛掉了; 2個哨兵中的一個就會做一個選舉，選舉一個哨兵出來，執行故障轉移; 如果5個哨兵中有3個哨兵都是運行的，那麼故障轉移就會被允許執行
6、configuration epoch版本號
哨兵會對一套redis master+slave進行監控，有相應的監控的配置
執行切換的那個哨兵，會從要切換到的新master（salve->master）那裏得到一個configuration epoch版本號，每次切換的version號都必須唯一
如果第一個選舉出的哨兵切換失敗，其他哨兵，會等待failover-timeout時間，然後接替繼續執行切換，此時會重新獲取一個新的configuration epoch，作爲新的version號
7、configuraiton傳播
哨兵完成切換之後，會在自己本地更新生成最新的master配置，然後同步給其他的哨兵，通過pub/sub消息機制
這裏之前的version號就很重要了，因爲各種消息都是通過一個channel去發佈和監聽的，所以一個哨兵完成一次新的切換之後，新的master配置是跟着新的version號的
其他的哨兵都是根據版本號的大小來更新自己的master配置的
經典的3節點方式部署哨兵集羣
練習如何操作部署哨兵集羣，如何基於哨兵進行故障轉移，還有一些企業級的配置方案
1、哨兵的配置文件（最小的配置）
sentinel.conf
每一個哨兵都可以去監控多個maser-slaves的主從架構。因爲可能公司裏，爲不同的項目，部署了多個master-slaves的redis主從集羣。相同的一套哨兵集羣，就可以去監控不同的多個redis主從集羣。給每個redis主從集羣分配一個邏輯的名稱
最小的哨兵配置，如果發生master-slave故障轉移，或新的哨兵進程加入哨兵集羣，那麼哨兵會自動更新自己的配置文件
# 監控名字爲mymaster
sentinel monitor mymaster 127.0.0.1 6379 2 # 最後一個值是quorum
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
# 監控名字爲resque
sentinel monitor resque 192.168.1.3 6380 4
sentinel down-after-milliseconds resque 10000
sentinel failover-timeout resque 180000
sentinel parallel-syncs resque 5
上面這段配置，就監控了兩個master node
配置分析：
sentinel monitor mymaster 127.0.0.1 6379 #指定對一個master的監控，給監控的master指定一個名稱，可配置多個master做數據拆分
sentinel down-after-milliseconds mymaster 60000 #超多少毫秒跟一個redis實例斷了連接，哨兵就可能認爲這個redis實例掛了
sentinel failover-timeout mymaster 180000 # 執行故障轉移的timeout超時時長
sentinel parallel-syncs mymaster 1 # 新的master別切換之後，同時有多少個slave被切換到去連接新master，重新做同步，數字越低，花費的時間越多
上面的三個配置，都是針對某個監控的master配置的，給其指定上面分配的名稱即可
sentinel monitor master-group-name hostname port quorum
parallel-syncs的解釋：
假設redis是1個master，4個slave
master宕機，4個slave中有1個切換成master，剩下3個slave就要掛到新的master上面去
這時，如果parallel-syncs是1，那麼3個slave，一個一個地掛接到新的master上面去，1個掛接完，而且從新的master sync完數據之後，再掛接下一個。
如果parallel-syncs是3，那麼一次性就會把所有slave掛接到新的master上去
2、在eshop-cache03上再部署一個redis
只要安裝redis就可以了，不需要去部署redis實例的啓動
wget http://downloads.sourceforge.net/tcl/tcl8.6.1-src.tar.gz
tar -xzvf tcl8.6.1-src.tar.gz
cd /usr/local/tcl8.6.1/unix/
./configure
make && make install
使用redis-3.2.8.tar.gz（截止2017年4月的最新穩定版）
tar -zxvf redis-3.2.8.tar.gz
cd redis-3.2.8
make && make test
make install
2、正式的配置
哨兵默認用26379端口，默認不能跟其他機器在指定端口連通，只能在本地訪問
mkdir /etc/sentinal
mkdir -p /var/sentinal/5000
/etc/sentinel/5000.conf
port 5000
bind 192.168.31.187
dir /var/sentinal/5000
sentinel monitor mymaster 192.168.31.187 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
port 5000
bind 192.168.31.19
dir /var/sentinal/5000
sentinel monitor mymaster 192.168.31.187 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
port 5000
bind 192.168.31.227
dir /var/sentinal/5000
sentinel monitor mymaster 192.168.31.187 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
3、啓動哨兵進程
在eshop-cache01、eshop-cache02、eshop-cache03三臺機器上，分別啓動三個哨兵進程，組成一個集羣，觀察一下日誌的輸出
redis-sentinel /etc/sentinal/5000.conf
redis-server /etc/sentinal/5000.conf --sentinel
日誌裏會顯示出來，每個哨兵都能去監控到對應的redis master，並能夠自動發現對應的slave
哨兵之間，互相會自動進行發現，用的就是pub/sub，消息發佈和訂閱channel消息系統和機制
4、檢查哨兵狀態
redis-cli -h 192.168.31.187 -p 5000
sentinel master mymaster
SENTINEL slaves mymaster
SENTINEL sentinels mymaster
SENTINEL get-master-addr-by-name mymaster
對項目中的哨兵節點進行管理以及高可用redis集羣的容災演練
1、哨兵節點的增加和刪除
增加sentinal，會自動發現
刪除sentinal的步驟
（1）停止sentinal進程
（2）SENTINEL RESET *，在所有sentinal上執行，清理所有的master狀態
（3）SENTINEL MASTER mastername，在所有sentinal上執行，查看所有sentinal對數量是否達成了一致
2、slave的永久下線
讓master摘除某個已經下線的slave：SENTINEL RESET mastername，在所有的哨兵上面執行
3、slave切換爲Master的優先級
slave->master選舉優先級：slave-priority，值越小優先級越高
4、基於哨兵集羣架構下的安全認證
每個slave都有可能切換成master，所以每個實例都要配置兩個指令
master上啓用安全認證，requirepass
master連接口令，masterauth
sentinal，sentinel auth-pass <master-group-name> <pass>
5、容災演練
通過哨兵看一下當前的master：SENTINEL get-master-addr-by-name mymaster
把master節點kill -9掉，pid文件也刪除掉
查看sentinal的日誌，是否出現+sdown字樣，識別出了master的宕機問題; 然後出現+odown字樣，就是指定的quorum哨兵數量，都認爲master宕機了
（1）三個哨兵進程都認爲master是sdown了
（2）超過quorum指定的哨兵進程都認爲sdown之後，就變爲odown
（3）哨兵1是被選舉爲要執行後續的主備切換的那個哨兵
（4）哨兵1去新的master（slave）獲取了一個新的config version
（5）嘗試執行failover
（6）投票選舉出一個slave區切換成master，每隔哨兵都會執行一次投票
（7）讓salve，slaveof noone，不讓它去做任何節點的slave了; 把slave提拔成master; 舊的master認爲不再是master了
（8）哨兵就自動認爲之前的187:6379變成了slave了，19:6379變成了master了
（9）哨兵去探查了一下187:6379這個salve的狀態，認爲它sdown了
所有哨兵選舉出了一個，來執行主備切換操作
如果哨兵的majority都存活着，那麼就會執行主備切換操作
再通過哨兵看一下master：SENTINEL get-master-addr-by-name mymaster
嘗試連接一下新的master
故障恢復，再將舊的master重新啓動，查看是否被哨兵自動切換成slave節點
（1）手動殺掉master
（2）哨兵能否執行主備切換，將slave切換爲master
（3）哨兵完成主備切換後，新的master能否使用
（4）故障恢復，將舊的master重新啓動
（5）哨兵能否自動將舊的master變爲slave，掛接到新的master上面去，而且也是可以使用的
6、哨兵的生產環境部署
daemonize yes
logfile /var/log/sentinal/5000
mkdir -p /var/log/sentinal/5000
哨兵機制雖然可以做到高可用，但是無法做到分佈式，數據都存在一個master中。
而分佈式，就需要集羣。集羣還支持擴容。