Redis高可用方案學習，主從複製+哨兵機制

我所在的公司是一家電商公司，一直有使用Redis做緩存，最近流量越來越大，開始有計劃的把一大批熱點數據放到Redis中緩存起來，緩解數據庫壓力，為了保證線上服務不出問題，同時避免緩存雪崩等一系列問題出現，計劃用哨兵機制保證Redis的高可用。今天把在網上整理的資料分享出來。

為了達到redis的高可用，有兩種部署方式：主從複製+哨兵機制；集群模式。哨兵機制是redis2.8開始支持。集群模式是redis3.0開始支持。

主從複製的意義：

主從複製可以把主節點的數據複製給從節點。從節點可以備份主節點的數據，起到主節點down調，頂上來接替主節點工作的作用。也可以起到分擔主節點讀壓力的作用。

沒有哨兵機制的時候，主從複製結構部署存在的問題是什麼？也可以說redis主節點發生故障如何解決？

如果主節點down調，主從切換需要人工介入。

主從切換步驟為：

1、啟用從節點為主節點。命令：slaveof no one

2、舊主節點的其他從節點變成新主節點的從節點。命令：slaveof new master

3、通知應用方redis主節點變成了新主節點。 修改客戶端調用的地址並重啟客戶端。

4、舊主節點變成新主節點的從節點。 命令：slaveof new master

哨兵機制存在的意義：

為了實現redis故障轉移的自動化。自動發現，自動轉移。不需要人工參與。

哨兵機制是怎樣的部署結構？

結合上圖，主從複製節點是數據節點，哨兵機制部署的節點是監控節點，它們都是redis實例。但是哨兵節點不存儲數據，它們監控主從數據節點的狀態，若哨兵判定主節點down掉後，就會自動執行上邊提到的手工操作的4步。

哨兵節點自動化完成故障轉移的過程：

哨兵機制是怎樣判斷主節點down調的？

哨兵機制是建立了多個哨兵節點，它們共同監控數據節點的運行狀況。同時哨兵節點之間也互相通信。交換對主從節點的監控狀況。下面提到兩個概念：

主觀下線和客觀下線：一個哨兵節點判定主節點down掉是主觀下線。只有半數個哨兵節點都主觀判定主節點down掉，此時多個哨兵節點交換主觀判定結果，才會判定主節點客觀下線。

基本上哪個哨兵節點最先判斷出這個主節點客觀下線，就會在各個哨兵節點中發起投票機制，每個哨兵都投自己為領導者。最終被投為領導者的哨兵節點完成主從自動化切換的過程。當判斷為主觀下線時，不會進行主從切換過程。

總結：

肉多嚼不爛，一個一個啃。

能讓工具（程序）去做的事情，就不要自己去做。