為什么要有Redis高可用？
痛點：
- 如果一個服務(wù)的redis，只有一個master節(jié)點，那哪天接口機跟redis機器網(wǎng)絡(luò)不通，或者redis機器故障了，不就訪問不了Redis了，如果服務(wù)強依賴redis，那不就崩了
- master多節(jié)點級別的高可用：如果redis有master節(jié)點，以及還有slave節(jié)點，那如果網(wǎng)絡(luò)不通、redis機器故障了，哪怕故障1個小時，整個服務(wù)的redis都受影響，那如果redis有多個master節(jié)點（4個），數(shù)據(jù)分片到這些master里面，那redis機器如果只是掛了一個機器，受影響也是1/4的數(shù)據(jù)。損失減少3/4
- 地區(qū)級別的redis高可用：如果服務(wù)是南北都有部署的，廣州訪問廣州地區(qū)的redis，北京訪問北京的redis。如果北京地區(qū)redis掛了，可以北京地區(qū)連廣州redis，或者直接北京請求轉(zhuǎn)發(fā)到廣州；或者客戶端收到北京失敗請求后，重試到廣州
高可用的手段
高可用的本質(zhì)是有備份，在出現(xiàn)故障的時候，有backup可以提供服務(wù)。
所以問題核心是備份，那么怎么備份呢？
一下按幾個層次來簡單解析一下：
持久化：
解決的痛點：數(shù)據(jù)落盤，不會因為redis掛了內(nèi)存數(shù)據(jù)都丟了
redis數(shù)據(jù)存在內(nèi)存的，如果redis掛了，那么重啟后內(nèi)存數(shù)據(jù)就丟失，沒有備份。此時就是需要持久化了，即把redis存入的數(shù)據(jù)，同時也寫一份到磁盤，在redis掛了重啟的時候，可以重新導(dǎo)入磁盤數(shù)據(jù)，來達到恢復(fù)的目的。
好處：
- 有了磁盤的備份，故障的時候，可以通過磁盤數(shù)據(jù)恢復(fù)
壞處：
- 依然是單點服務(wù)，數(shù)據(jù)恢復(fù)的時候需要時間，這個時間長短要看數(shù)據(jù)大小而定，恢復(fù)過程中，服務(wù)依然是不可用
- 非自動化，要手動恢復(fù)
主從同步
解決的痛點：多節(jié)點備份數(shù)據(jù)
上面說的持久化，痛點是在故障的時候，還得手動通過磁盤文件恢復(fù)。
那么主從同步可以解決這個痛點
具體是這么做的：redis主節(jié)點，掛N個從節(jié)點，slave節(jié)點實時同步master節(jié)點的數(shù)據(jù)，在master掛了的時候，可以立刻把slave提升成為master節(jié)點。
因為slave有了master的所有數(shù)據(jù)，因此可以直接切換，不用從磁盤恢復(fù)數(shù)據(jù)，大大縮短這個恢復(fù)時間。
好處：
- 故障時候，不用從磁盤恢復(fù)數(shù)據(jù)，減短故障時間
- slave節(jié)點一直保持同步，所以數(shù)據(jù)是最新的，可以直接提升為master
- 讀寫分離，master接收寫請求，slave接收讀請求。
壞處：
- 如果代碼寫死了鏈接master節(jié)點，此時切換了slave節(jié)點，代碼就要更改redis連接配置。解決方案：因此需要設(shè)置一個VIP，中間件IP，客戶端連接這個VIP即可，VIP后面怎么轉(zhuǎn)發(fā)，對代碼透明。
- 非自動切換，需要手動切換，深夜時間無人值班，沒發(fā)現(xiàn)即時會讓故障時間延長。
哨兵模式（Sentinel）
解決的痛點：自動故障轉(zhuǎn)移
出故障的時候可能夜晚，又必須要精通的運維才能快速搞定，否則一定崩了，影響服務(wù)和用戶。
有了主從同步，數(shù)據(jù)得以備份，以備故障的時候可以容器。但是這個故障切換要手動操作，哨兵模式就是解決這個痛點：自動轉(zhuǎn)移故障
工作原理：
sentinel哨兵也是一個集群，而且是獨立于redis集群的一個服務(wù)。
因此哨兵是多個節(jié)點的，他的本質(zhì)原理就是，每個哨兵每秒定時發(fā)送ping給master，等master回應(yīng)
如果回應(yīng)正常，那沒問題
如果回應(yīng)超時，那就需要關(guān)注。但是超時也有可能很多原因，比如網(wǎng)絡(luò)不通暢、偶發(fā)的丟包等等。
假設(shè)有3個哨兵：
如果只有一個哨兵得不到回應(yīng)，他會標識master 主觀下線，即只是他自己認為master下線了
但另外兩個哨兵是正常的，那就說明master沒有真的下線，可能只是哨兵1網(wǎng)絡(luò)問題
這樣就有個好處，必須要多數(shù)哨兵認為master下線了，才會切換主從。
哨兵自己認為master掛了，這種叫主觀下線
半數(shù)以上哨兵認為master掛了，他們通過互相信息同步，就認為master是客觀下線
這個時候，就需要走主從切換流程了
主從切換原理：
正常情況下，多個slave配置，都配置了slaveof master
如果master被哨兵認為客觀下線了，此時就要進行一次“投票”，從slave里面選出新的master。
具體就是修改配置文件、重啟服務(wù)，這幾個操作的自動化
簡化理解
其實就好比平常工作中，寫了個腳本，定時掃描漏單之類的，這個定時腳本也要高可用，所以就部署在多個接口機上。
然后腳本定時探測一下master是否正常，多數(shù)發(fā)現(xiàn)不正常了，就觸發(fā)自動更換配置文件，reload服務(wù)。
就是這么個道理
問題
問題1. 如果代碼寫死鏈接的masterip， 這樣切換了，代碼還得發(fā)版上線才能生效，所以代碼不能這么說傻叉寫死一個IP。
解決：需要有一個類似中間件的組件，來做這個事。比如mysql就有個中間件，端口就是127.0.0.1:9981服務(wù)，后面轉(zhuǎn)發(fā)到redis真實IP 。當(dāng)然故障切換后，這個中間件得知道m(xù)aster是誰了。這個也是可以通過下發(fā)配置通知的？
問題：還是客戶端直接訪問的sentinel ? sentinel擔(dān)任起中間件的角色？因為它知道m(xù)aster和slave具體信息
