關于Redis高可用方案，看到較多的是keepalived、zookeeper方案。
keepalived是主備模式，意味着總有一台浪費着。
zookeeper工作量成本偏高。
本文主要介紹下使用官方sentinel做redis高可用方案的設計。
Redis Sentinel
Sentinel介紹
Sentinel是Redis官方為叢集提供的高可用解決方案。 在實際項目中可以使用sentinel去做redis自動故障轉移，減少人工介入的工作量。
另外sentinel也給用戶端提供了監控消息的通知，這樣用戶端就可根據消息類型去判斷伺服器的狀态，去做對應的适配操作。
下面是Sentinel主要功能清單：
Monitoring：Sentinel持續檢查叢集中的master、slave狀态，判斷是否存活。
Notification：在發現某個redis執行個體死的情況下，Sentinel能通過API通知系統管理者或其他程式腳本。
Automatic failover：如果一個master挂掉後，sentinel立馬啟動故障轉移，把某個slave提升為master。其他的slave重新配置指向新master。
Configuration provider：對于用戶端來說sentinel通知是有效可信賴的。用戶端會連接配接sentinel去請求目前master的位址，一旦發生故障sentinel會提供新位址給用戶端。
Sentinel配置
Sentinel本質上隻是一個運作在特殊模式下的redis伺服器，通過不同配置來區分提供服務。 sentinel.conf配置：
啟動後Sentinel會：
以10秒一次的頻率，向被監視的master發送info指令，根據回複擷取master目前資訊。
以1秒一次的頻率，向所有redis伺服器、包含sentinel在内發送PING指令，通過回複判斷伺服器是否線上。
以2秒一次的頻率，通過向所有被監視的master，slave伺服器發送包含目前sentinel，master資訊的消息。
另外建議sentinel至少起3個執行個體以上，并配置2個執行個體同意即可發生轉移。 5個執行個體，配置3個執行個體同意以此類推。
故障轉移消息接收的3種方式
Redis伺服器一旦發送故障後，sentinel通過raft算法投票選舉新master。 故障轉移過程可以通過sentinel的API擷取/訂閱接收事件消息。
腳本接收
//當故障轉移期間，可以指定一個“通知”腳本用來告知系統管理者，目前叢集的情況。 //腳本被允許執行的最大時間為60秒，如果逾時，腳本将會被終止(KILL)
服務間接接收
這種方式在第二種基礎上擴充了一層，即應用端不直接訂閱sentinel。 單獨做服務去幹這件事情，然後應用端提供API供這個服務回調通知。 這樣做的好處在于：
減少應用端監聽失敗出錯的可能性。
應用端由主動方變成被動方，降低耦合。
性能提高，輪詢變回調。
獨立成服務可擴充性更高。
比如：
1：以後換掉sentinel，我們隻需要動服務即可，應用端無需更改。
2：可以在服務内多增加一層守護線程去主動拉取redis狀态，這樣可確定即使sentinel不生效，也能及時察覺redis狀态，并通知到應用端。 當然這種情況很極端，因為sentinel配的也是多節點，同時挂的幾率非常小。 示例： 應用端提供回調API，在這個API邏輯下去重新整理記憶體中的Redis連接配接。
總結
各種sentinel通知消息類型見官方文檔，項目中使用的redis用戶端在github上。本文分享了樓主在項目中做Redis高可用的經驗，希望對大家有所幫助。
在人力物力滿足的情況下還是推薦使用zookeeper方案的。 隻有三五杆槍的情況下也就退而求其次，利用最小成本滿足需求并保留可擴充性。
相信沒有最好的架構，隻有更合适的架構。
參考：
http://redis.io/topics/sentinel近期熱文推薦：
1.600+ 道 Java面試題及答案整理(2021最新版)
2.終于靠開源項目弄到 IntelliJ IDEA 激活碼了，真香！
3.阿裡 Mock 工具正式開源，幹掉市面上所有 Mock 工具！
4.Spring Cloud 2020.0.0 正式釋出，全新颠覆性版本！
5.《Java開發手冊（嵩山版）》最新釋出，速速下載下傳！
覺得不錯，别忘了随手點贊+轉發哦！