分佈式Redis集羣系列【上】
1.集羣概述
2.主從複製
3.哨兵機制
====================================
一. 集羣概述
先來簡單瞭解下redis中提供的集羣策略, 雖然redis有持久化功能能夠保障redis服務器宕機也能恢復並且只有少量
的數據損失，但是由於所有數據在一臺服務器上，如果這臺服務器出現硬盤故障，那就算是有備份也仍然不可避免
數據丟失的問題。
在實際生產環境中，我們不可能只使用一臺redis服務器作爲我們的緩存服務器，必須要多臺實現集羣，避免出現
單點故障；
redis集羣演變過程
-
單機版
核心技術：持久化
持久化是最簡單的高可用方法（有時甚至不被歸爲高可用的手段），主要作用是數據備份，即將數據存儲在硬盤，保證數據不會因進程退出而丟失。 -
複製
複製是高可用Redis的基礎，哨兵和集羣都是在複製基礎上實現高可用的。複製主要實現了數據的多機備份，以及對於讀操作的負載均衡和簡單的故障恢復。缺陷是故障恢復無法自動化；寫操作無法負載均衡；存儲能力受到單機的限制。 -
哨兵
在複製的基礎上，哨兵實現了自動化的故障恢復。缺陷是寫操作無法負載均衡；存儲能力受到單機的限制。 -
集羣
通過集羣，Redis解決了寫操作無法負載均衡，以及存儲能力受到單機限制的問題，實現了較爲完善的高可用方案
二. 主從複製
複製的作用是把redis的數據庫複製多個副本部署在不同的服務器上，如果其中一臺服務器出現故障，也能快速遷
移到其他服務器上提供服務。 複製功能可以實現當一臺redis服務器的數據更新後，自動將新的數據同步到其他服
務器上
主從複製就是我們常見的master/slave模式， 主數據庫可以進行讀寫操作，當寫操作導致數據發生變化時會自動將
數據同步給從數據庫。而一般情況下，從數據庫是隻讀的，並接收主數據庫同步過來的數據。 一個主數據庫可以有
多個從數據庫
在redis中配置master/slave是非常容易的，只需要在從數據庫的配置文件中加入slaveof 主數據庫地址 端口。 而
master 數據庫不需要做任何改變
準備兩臺服務器，分別安裝redis ， server1 server2
- 在server2的redis.conf文件中增加 slaveof server1-ip 6379 、 同時將bindip註釋掉，允許所 有ip訪問
- 啓動server2
- 訪問server2的redis客戶端，輸入 INFO replication
- 通過在master機器上輸入命令，比如set foo bar 、 在slave服務器就能看到該值已經同步過來了
原理
全量複製
Redis全量複製一般發生在Slave初始化階段，這時Slave需要將Master上的所有數據都複製一份。具體步驟
完成上面幾個步驟後就完成了slave服務器數據初始化的所有操作，savle服務器此時可以接收來自用戶的讀請求。
master/slave 複製策略是採用樂觀複製，也就是說可以容忍在一定時間內master/slave數據的內容是不同的，但是
兩者的數據會最終同步。具體來說，redis的主從同步過程本身是異步的，意味着master執行完客戶端請求的命令
後會立即返回結果給客戶端，然後異步的方式把命令同步給slave。
這一特徵保證啓用master/slave後 master的性能不會受到影響。
但是另一方面，如果在這個數據不一致的窗口期間，master/slave因爲網絡問題斷開連接，而這個時候，master
是無法得知某個命令最終同步給了多少個slave數據庫。不過redis提供了一個配置項來限制只有數據至少同步給多
少個slave的時候，master纔是可寫的：
min-slaves-to-write 3 表示只有當3個或以上的slave連接到master，master纔是可寫的
min-slaves-max-lag 10 表示允許slave最長失去連接的時間，如果10秒還沒收到slave的響應，則master認爲該
slave以斷開
全量複製消耗
- bgsave時間
- rdb文件網絡傳輸
- 從節點請求請求數據時間
- 從節點加載rdb的時間
- 可能的aof重寫時間
缺點
1.由於所有的寫操作都是先在Master上操作，然後同步更新到Slave上，所以從Master同步到Slave機器有一定的延遲，當系統很繁忙的時候，延遲問題會更加嚴重，Slave機器數量的增加也會使這個問題更加嚴重。
2.當主機宕機之後，將不能進行寫操作，需要手動將從機升級爲主機，從機需要重新制定master
簡單總結：
- 一個master可以有多個Slave
- 一個slave只能有一個master
- 數據流向是單向的，只能從主到從
增量複製
從redis 2.8開始，就支持主從複製的斷點續傳，如果主從複製過程中，網絡連接斷掉了，那麼可以接着上次複製的
地方，繼續複製下去，而不是從頭開始複製一份
master node會在內存中創建一個backlog，master和slave都會保存一個replica offset還有一個master id，offset
就是保存在backlog中的。如果master和slave網絡連接斷掉了，slave會讓master從上次的replica offset開始繼續
複製
但是如果沒有找到對應的offset，那麼就會執行一次全量同步
無硬盤複製
前面我們說過，Redis複製的工作原理基於RDB方式的持久化實現的，也就是master在後臺保存RDB快照，slave接
收到rdb文件並載入，但是這種方式會存在一些問題
- 當master禁用RDB時，如果執行了複製初始化操作，Redis依然會生成RDB快照，當master下次啓動時執行該
RDB文件的恢復，但是因爲複製發生的時間點不確定，所以恢復的數據可能是任何時間點的。就會造成數據出現問
題 - 當硬盤性能比較慢的情況下（網絡硬盤），那初始化複製過程會對性能產生影響
因此2.8.18以後的版本，Redis引入了無硬盤複製選項，可以不需要通過RDB文件去同步，直接發送數據，通過以
下配置來開啓該功能
repl-diskless-sync yes
master**在內存中直接創建rdb，然後發送給slave，不會在自己本地落地磁盤了
三. 哨兵機制
在前面講的master/slave模式，在一個典型的一主多從的系統中，slave在整個體系中起到了數據冗餘備份和讀寫
分離的作用。當master遇到異常終端後，需要從slave中選舉一個新的master繼續對外提供服務，這種機制在前面
提到過N次，比如在zk中通過leader選舉、kafka中可以基於zk的節點實現master選舉。所以在redis中也需要一種
機制去實現master的決策，redis並沒有提供自動master選舉功能，而是需要藉助一個哨兵來進行監控
哨兵概述
顧名思義，哨兵的作用就是監控Redis系統的運行狀況，哨兵是一個獨立的進程，它的功能包括兩個
- 監控(monitoring)：Sentinel 會不斷地檢查你的主服務器和從服務器是否運作正常。
- 自動故障轉移(Automatic failover)：master出現故障時自動將slave數據庫升級爲master
- 提醒(Notifation)：當被監控的某個 Redis 服務器出現問題時， Sentinel 可以通過 API 向管理員或者其他應用程序發送通知。
爲了解決master選舉問題，又引出了一個單點問題，也就是哨兵的可用性如何解決，在一個一主多從的Redis系統
中，可以使用多個哨兵進行監控任務以保證系統足夠穩定。此時哨兵不僅會監控master和slave，同時還會互相監
控；這種方式稱爲哨兵集羣，哨兵集羣需要解決故障發現、和master決策的協商機制問題
sentinel之間的相互感知
sentinel節點之間會因爲共同監視同一個master從而產生了關聯，一個新加入的sentinel節點需要和其他監視相同
master節點的sentinel相互感知，首先
- 需要相互感知的sentinel都向他們共同監視的master節點訂閱channel:sentinel:hello
- 新加入的sentinel節點向這個channel發佈一條消息，包含自己本身的信息，這樣訂閱了這個channel的sentinel
就可以發現這個新的sentinel - 新加入得sentinel和其他sentinel節點建立長連接
基本原理
關於哨兵的原理，關鍵是瞭解以下幾個概念：
主觀下線：在心跳檢測的定時任務中，如果其他節點超過一定時間沒有回覆，哨兵節點就會將其進行主觀下線。顧名思義，主觀下線的意思是一個哨兵節點“主觀地”判斷下線；與主觀下線相對應的是客觀下線。
客觀下線：哨兵節點在對主節點進行主觀下線後，會通過sentinel is-master-down-by-addr命令詢問其他哨兵節點該主節點的狀態；如果判斷主節點下線的哨兵數量達到一定數值，則對該主節點進行客觀下線。
需要特別注意的是，客觀下線是主節點纔有的概念；如果從節點和哨兵節點發生故障，被哨兵主觀下線後，不會再有後續的客觀下線和故障轉移操作。
定時任務：每個哨兵節點維護了3個定時任務。定時任務的功能分別如下：
- 每10秒通過向主從節點發送info命令獲取最新的主從結構；
發現slave節點
確定主從關係 - 每2秒通過發佈訂閱功能獲取其他哨兵節點的信息；SUBSCRIBE c2 PUBLISH c2 hello-redis
交互對節點的“看法”和自身情況 - 每1秒通過向其他節點發送ping命令進行心跳檢測，判斷是否下線（monitor）。
心跳檢測，失敗判斷依據
選舉領導者哨兵節點：當主節點被判斷客觀下線以後，各個哨兵節點會進行協商，選舉出一個領導者哨兵節點，並由該領導者節點對其進行故障轉移操作。
監視該主節點的所有哨兵都有可能被選爲領導者，選舉使用的算法是Raft算法；Raft算法的基本思路是先到先得：即在一輪選舉中，哨兵A向B發送成爲領導者的申請，如果B沒有同意過其他哨兵，則會同意A成爲領導者。選舉的具體過程這裏不做詳細描述，一般來說，哨兵選擇的過程很快，誰先完成客觀下線，一般就能成爲領導者。
故障轉移：選舉出的領導者哨兵，開始進行故障轉移操作，該操作大體可以分爲3個步驟：
在從節點中選擇新的主節點：選擇的原則是，
- 首先過濾掉不健康的從節點；
- 然後選擇優先級最高的從節點（由replica-priority指定）；如果優先級無法區分，
- 則選擇複製偏移量最大的從節點；如果仍無法區分，
- 則選擇runid最小的從節點。
更新主從狀態：通過slaveof no one命令，讓選出來的從節點成爲主節點；並通過slaveof命令讓其他節點成爲其從節點。
將已經下線的主節點（即6379）保持關注，當6379從新上線後設置爲新的主節點的從節點
master的故障發現
sentinel節點會定期向master節點發送心跳包來判斷存活狀態，一旦master節點沒有正確響應，sentinel會把
master設置爲“主觀不可用狀態”，然後它會把“主觀不可用”發送給其他所有的sentinel節點去確認，當確認的
sentinel節點數大於>quorum時，則會認爲master是“客觀不可用”，接着就開始進入選舉新的master流程；但是
這裏又會遇到一個問題，就是sentinel中，本身是一個集羣，如果多個節點同時發現master節點達到客觀不可用狀
態，那誰來決策選擇哪個節點作爲maste呢？這個時候就需要從sentinel集羣中選擇一個leader來做決策。而這裏
用到了一致性算法Raft算法、它和Paxos算法類似，都是分佈式一致性算法。但是它比Paxos算法要更容易理解；
Raft和Paxos算法一樣，也是基於投票算法，只要保證過半數節點通過提議即可;
動畫演示地址：http://thesecretlivesofdata.com/raft/
配置實現
通過在這個配置的基礎上增加哨兵機制。在其中任意一臺服務器上創建一個sentinel.conf文件，文件內容
sentinel monitor name ip port quorum
其中name表示要監控的master的名字，這個名字是自己定義。 ip和port表示master的ip和端口號。 最後一個1表示最低 通過票數，也就是說至少需要幾個哨兵節點統一纔可以，後面會具體講解
port 6040
sentinel monitor mymaster 192.168.11.131 6379 1
sentinel down-after-milliseconds mymaster 5000 --表示如果5s內mymaster沒響應，就認爲SDOWN
sentinel failover-timeout mymaster 15000 --表示如果15秒後,mysater仍沒活過來，則啓動failover，從剩下的
slave中選一個升級爲master
兩種方式啓動哨兵
redis-sentinel sentinel.conf
redis-server /path/to/sentinel.conf --sentinel
哨兵監控一個系統時，只需要配置監控master即可，哨兵會自動發現所有slave；
這時候，我們把master關閉，等待指定時間後（默認是30秒），會自動進行切換，會輸出如下消息
img
+sdown表示哨兵主管認爲master已經停止服務了，+odown表示哨兵客觀認爲master停止服務了。關於主觀和客
觀，後面會給大家講解。接着哨兵開始進行故障恢復，挑選一個slave升級爲master
+try-failover表示哨兵開始進行故障恢復
+failover-end 表示哨兵完成故障恢復
+slave表示列出新的master和slave服務器，我們仍然可以看到已經停掉的master，哨兵並沒有清楚已停止的服務
的實例，這是因爲已經停止的服務器有可能會在某個時間進行恢復，恢復以後會以slave角色加入到整個集羣中
注：希望大家技術越來越6p
