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