# 主從複製 ### Master-Slave主從概念 同時執行多個redis服務端,其中一個作為主(master),其他的一個或多個作為從(slave),主從之間通過網路進行通訊,slave通過複製master的資料來保持與master的資料同步,實現資料冗餘; 在Redis中,配置主從複製非常簡單,Redis允許slave例項對master進行完整拷貝,在連線斷開時,slave會自動重新連線至主例項,並儘可能與master保持同步; ### 三個主要機制: - 當連線可用時,master將傳送命令流到slave來使salve保持更新,以下操作將引發該操作,對msater資料的寫入操作(包括刪除更新),key過期; - master和slave節點都會進行超時檢測,當連線不穩定時,slave將盡快重新連線並進行部分重新同步,即不需要完全重新同步; - 若無法進行部分重新同步,則slave將發起完全重新同步,master會將最新的資料快照發送給slave,後續的操作仍然是傳送命令流; ### 其他特性: 主從之間,採用非同步複製,複製過程中依然可以正常響應客戶端操作,支援一主多從,且從節點還可以類似的級聯其他從節點,如圖所示:  ### 主從複製的作用: - 使用主從複製,能夠避免Redis的單點故障,實現資料防災備份; - 可配置主節點執行寫入,多個從節點分擔查詢,實現讀寫分離獲得更好的效能 **注意:**使用主從來做讀寫分離時,意味主節點自身沒有任何持久化資料;如果配置了哨兵,一旦節點重啟,則將使用空資料進行同步,導致從節點覆蓋所有持久化資料,這是非常危險的,牆裂建議在主節點和從節點上開啟持久化,如果一定要關閉,則必須配置主節點禁止哨兵自動重啟故障節點;具體故障模式:連線 ### 配置: ```shell #配置檔案中按以下方式新增主節點的ip 和埠即可 replicaof 192.168.1.1 6379 #若主節點配置了授權密碼則需要指定密碼 masterauth 密碼 #主節點通過以下方式設定授權密碼 requirepass 密碼 #客戶端連線後需要先驗證密碼 auth 密碼 #可通過以下指令檢視當前連線的服務的主從資訊 info replication ``` ### 副本只讀: 預設情況下副本是隻讀的,若需要可以通過配置`replica-read-only`為`no`來使副本變為可寫的,但是要強調的是副本寫入的資料,僅寫入到當前副本本地,不會同步至任何節點,包括當前副本的副本;當副本重啟後這寫資料將消失,即臨時資料; # 哨兵 哨兵(Sentinel) 是為redis提供了高可用性(high available/HA),使用Sentinel部署Redis時,可實現在無需人工干預的情況下,自動完成固定型別的故障修復;是Redis儘可能處於正常工作狀態; 哨兵的主要功能: - 叢集監控:監控redis各個節點是否正常工作; - 訊息通知:當某個節點出現故障時,可通過API\通知系統管理員或是其他程式; - 故障轉移(failover):當master無法無法正常工作時,哨兵可以啟動故障轉移過程,該過程會將某一個slave節點提升為master節點,並主動通知使用redis伺服器的應用程式要使用新的地址; - ​ 配置中心:當客戶端連線至哨兵時,可通過哨兵獲取可用的Redis服務資訊; 哨兵的分散式性質: Sentinel本身是一個分散式系統,即會有多個Sentinel程序通過網路協同合作,具有以下優點: - 當多個哨兵就某一master不可用這一事實達成共識,才會進行故障轉移,降低了因網路波動造成誤報的可能性; - 即使一些哨兵程序無法工作時,其他可用的哨兵仍然能夠正常工作,提供了整個系統應對故障的能力; 反過來,如果只有單獨的一個哨兵程序實際上是沒有辦法提供高可用的; ## 啟動哨兵 哨兵的執行檔案本質就是redis的服務端,只不過執行的模式不同了,另外執行哨兵必須提供配置檔案,否則將拒絕啟動; 首先需要準備配置檔案,在下載的原始碼中找到`sentinel.conf` 為了後續方便修改可以將其複製到bin目錄下 指定master的地址和埠 ```properties sentinel monitor mymaster 127.0.0.1 6379 2 ``` 啟動哨兵的命令有兩種寫法: ```shell #方式1 redis-sentinel sentinel.conf #方式1 redis-server sentinel.conf --sentinel ``` 若啟動哨兵成功可以在控制檯中看到其輸出的master節點資訊;  預設情況下哨兵監聽在26379埠上,若開啟了防火牆則需要開放該埠,否則哨兵無法正常工作; ## 完成故障切換的過程 **故障切換的定義**: ​ 當master不可用時將一個可用的slave提升稱為master,使結點保持正常訪問; 基於網路存在不穩定性這個特性,一些時候某個哨兵程序可能無法與master正常通訊,但是這並不意味這master真的不可用了,哨兵無法就此認定master不可用這一事實,哨兵需要能夠檢測master是否客觀的不可用了,並在master不可用成為客觀事實後開始執行故障切換; 1. 每個Sentinel(哨兵)程序以每秒鐘一次的頻率向整個叢集中的Master主伺服器，Slave從伺服器 以及其他Sentinel(哨兵)程序傳送一個 PING 命令 2. 如果一個例項(instance)距離最後一次有效回覆 PING 命令的時間超過 down-after- milliseconds 選項所指定的值，則這個例項會被 Sentinel(哨兵)程序標記為主觀下線(sdown) 3. 如果一個Master主伺服器被標記為主觀下線(SDOWN)，則正在監視這個Master主伺服器的所有Sentinel(哨兵)程序要以每秒一次的頻率確認Master主伺服器的確進入了主觀下線狀態。 4. 當有足夠數量的 Sentinel(哨兵)程序(大於等於配置檔案指定的值)在指定的時間範圍內確認Master主伺服器進入了主觀下線狀態(SDOWN)， 則Master主伺服器會被標記為客觀下線(ODOWN)。 5. 在一般情況下， 每個Sentinel(哨兵)程序會以每 10 秒一次的頻率向叢集中的所有Master主伺服器、Slave從伺服器傳送 INFO 命令。 6. 當Master主伺服器被 Sentinel(哨兵)程序標記為客觀下線(ODOWN)時，Sentinel(哨兵)程序向下線的 Master主伺服器的所有 Slave從伺服器傳送 INFO 命令的頻率會從 10 秒一次改為每秒一次。 7. 若沒有足夠數量的 Sentinel(哨兵)程序同意 Master主伺服器下線， Master主伺服器的客觀下線狀態就會被移除。若 Master主伺服器重新向 Sentinel(哨兵)程序傳送 PING 命令返回有效回 復，Master主伺服器的主觀下線狀態就會被移除。 故障切換涉及到的事件和引數: - sdown:主觀下線,當某個哨兵與master之間在指定時間內無法正常通訊後該哨兵將產生sdown事件 - quorum(仲裁數):是一個整數,表示master從主觀下線變為客觀下線所需要的哨兵數量(但有quorum個哨兵與master通訊失敗則master進入主觀下線) - odown:當sdown的事件的數量達到指定值(quorum)時,將產odown事件,表示master客觀下線了; - majority(大多數):是一個整數,該值通過計算自動得出,計算公式為`floor(哨兵總數量/2)+1` floor為下取整 當odown產生時,會選出一個哨兵準備進行故障切換,在切換前該哨兵還需要獲得大多數(majority)哨兵的授權,授權成功則開始進行故障切換; 故障切換完成後,若先前宕機的節點(原來的master)恢復正常,則該節點會降為slave; ## 部署Sentinel的基本知識 - 哨兵應與分散式的形式存在,若哨兵僅部署一個則實際上沒有辦法提高可用性,當僅有的哨兵程序遇到問題退出後,則無法完成故障恢復; - 一個健壯的部署至少需要三個Sentinel例項 - 三個哨兵應該部署在相互的獨立的計算機或虛擬機器中; - Sentinel無法保證在執行故障轉移期間的寫入的資料是否能夠保留下來; ## 部署案例: 下例圖中名稱的釋義: S:sentinel M:master R:replace(slave) ### 1.不要採用下例部署  上述部署中若M1(包括S1,因為在同一個機器上)宕機,剩下的S2雖然可以認定M1主觀下線,但是卻無法得到大多數哨兵的授權並開始故障切換,因為此時majority為2; ### 2.簡單且實用的部署  上述部署由三個節點組成,每個節點都執行著Redis程序和Sentinel程序,結構簡單,安全性也有了提高; 當M1發生故障時,S2和S3可以就該故障達成一致,並且能夠授權進行故障切換,從而使得客戶端可以正常使用;但也存在丟失已寫入資料的情況,因為redis內部使用非同步複製,Master和Slave之間的資料在某個時間點可能不一致; **注意:**  由於網路存在分割槽性質,若客戶端C1和M1處於同一分割槽,但是該分割槽與S1,S2所在的分割槽無法通訊時,C1可以繼續向M1寫入資料,這寫資料將丟失,因為當網路恢復時,M1可會被降為slave,而丟棄自己原本的資料; 使用下例配置可緩解該問題: ```properties min-replicas-to-write 1 min-replicas-max-lag 5 ``` 上述配置表示,只要master無法寫入資料到任何一個slave超過5秒,則master停止接受寫入; ### 3.在客戶端部署哨兵 若某些原因導致沒有足夠的伺服器節點用於部署哨兵,則可以將哨兵部署至客戶端,如下所示  若M1出現故障,則S1,S2,S3可順利的進行故障切換;但要注意該部署可能出現案例2中的問題 當然你也可以在客戶端和服務端同時部署哨兵; ## 配置示例: ```properties #指出master地址和埠 以及仲裁數 sentinel monitor mymaster 127.0.0.1 6379 2 # 與master通訊超時時間,達到超時時間則sdown+1 sentinel down-after-milliseconds mymaster 60000 # 同一個master,開始新的故障轉移的時間(將是上一次的兩倍) # 若slave連線到錯誤的master超過這個時間後slave將被重新連線到正確的master # 取消正在進行中的故障轉移等待時間 # 按照parallel-syncs指定的配置進行復制的時間,超時候將不再受parallel-syncs的限制 sentinel failover-timeout mymaster 180000 # 發生故障轉移後,同時進行同步的副本數量 sentinel parallel-syncs mymaster 1 ``` # 叢集 Redis 叢集是一個提供在**多個Redis間節點間共享資料**的程式集。 Redis叢集並不支援處理多個keys的命令(如mset),因為這需要在不同的節點間移動資料,從而達不到像Redis那樣的效能,在高負載的情況下可能會導致不可預料的錯誤. Redis 叢集通過分割槽來提供**一定程度的可用性**,在實際環境中當某個節點宕機或者不可達的情況下繼續處理命令. Redis 叢集的優勢: - 自動分割資料到不同的節點上。 - 整個叢集的部分節點失敗或者不可達的情況下能夠繼續處理命令。 示意圖:  ## 叢集的資料分片 Redis 叢集沒有使用一致性hash, 而是引入了 **雜湊槽**的概念. Redis 叢集有16384個雜湊槽,每個key通過CRC16演算法校驗後對16384取模來決定放置哪個槽.叢集的每個節點負責一部分hash槽,舉個例子,比如當前叢集有3個節點,那麼: - 節點 A 包含 0 到 5500號雜湊槽. - 節點 B 包含5501 到 11000 號雜湊槽. - 節點 C 包含11001 到 16384號雜湊槽. 這種結構很容易新增或者刪除節點. 比如如果我想新添加個節點D, 我需要從節點 A, B, C中得部分槽到D上. 如果我想移除節點A,需要將A中的槽移到B和C節點上,然後將沒有任何槽的A節點從叢集中移除即可. 由於從一個節點將雜湊槽移動到另一個節點並不會停止服務,所以無論新增刪除或者改變某個節點的雜湊槽的數量都不會造成叢集不可用的狀態. 客戶端可以訪問任意節點進行讀寫操作,若雜湊槽不在當前訪問的節點redis會自動的將指令移動到相關節點上; ## 主從複製模型 為了使在部分節點失敗或者大部分節點無法通訊的情況下叢集仍然可用，叢集使用了主從複製模型,每個節點都會有至少一個slave; 叢集在沒有slave的情況下,如果某個節點故障了，那麼整個叢集就會以為缺少一部分槽而不可用. 然而如果在建立叢集時為每個節點都添加了從節點,在某個節點故障後,其從節點將被選舉為新的主節點,整個叢集就不會因找不到槽而不可用,當然若某個節點與其所有子節點都故障了那麼整個節點將不可用; ## 一致性保證 Redis 並不能保證資料的**強一致性**. 這意味這在實際中叢集在特定的條件下可能會丟失寫操作,主要有兩方面原因: - 主節點到從節點之間的指令複製是非同步完成的,主從之間在某個時間點可能不一致 - 出現網路分割槽,導致主節點可正常寫入,但是從節點已經被其他分割槽節點選舉為新的master,寫入的資料將丟失 ## 容錯性  當某master節點故障時,其他master節點將發起投票,若一半以上的master認為其不可用,則從該節點的從節點中(若存在)選舉新的master; 若該master沒有從節點,則叢集將不可用 另外當叢集一半以上的節點都不可用時則無論這些節點是否有從節點,叢集立即不可用; ## 建立叢集: Redis在5.0版本時放棄了Ruby叢集的方式,改為C語言編寫的 redis-cli方式,使得叢集的構建方式複雜度大大降低。 叢集至少需要三個節點,每個節點一個從節點總共為6個 1. 配置: 若要以叢集方式執行,則需要按以下方式修改配置檔案,以啟用叢集: ```properties cluster-enabled yes ``` 在實際開發中仍然建議使用單獨的虛擬機器來部署所有的redis節點,下例為了簡化操作,在同一臺虛擬機器上搭建叢集來進行測試: 2. 新增上述配置後將bin目錄複製6分名稱為7001-7006,埠從7001-7006  3. 分別啟動6個redis示例  4. 使用redis-cli建立叢集 ```shell redis-cli --cluster create 10.211.55.9:7001 10.211.55.9:7002 10.211.55.9:7003 10.211.55.9:7004 10.211.55.9:7005 10.211.55.9:7006 --cluster-replicas 1 ``` 過程中叢集將重寫配置檔案,需輸入`yes`確認 建立完成後提示如下資訊:  可以看到,叢集自動為每個master平均分配了雜湊槽,並且設定了一個slave 5. 連線叢集 ```shell ./redis-cli -h 10.211.55.9 -p 7001 -c # 引數 -c 即表示連線到叢集 ``` 6. 檢視叢集狀態 ```shell cluster info ``` 7. 檢視節點資訊,包括ip,port,id,槽,主/從; ```shell cluster nodes ``` ## 新增節點 Redis叢集支援動態擴充套件,期間redis可正常響應客戶端訪問 1. 首先製作新的redis例項埠為7007並啟動 2. 新增到叢集中 ```shell ./redis-cli --cluster add-node 10.211.55.9:7007 10.211.55.9:7001 ``` 新增成功:  3. 新的節點預設作為master,但是該master沒有分配槽位,使用前必須分配雜湊槽 下例表示從id為cc2e48268ccdd52d1c7840c8f9d2d7f15cc74c1b的節點移動1000個槽到cda3828e42e23dcbdb141db2fed221bc07c59f65節點 ```shell ./redis-cli --cluster reshard 10.211.55.9:7001 --cluster-from cc2e48268ccdd52d1c7840c8f9d2d7f15cc74c1b --cluster-to cda3828e42e23dcbdb141db2fed221bc07c59f65 --cluster-slots 1000 #--cluster-from 來源節點 多個之前用逗號隔開, all 表示從所有節點中平均分配 #--cluster-to 目標節點 #--cluster-slots 1000 移動雜湊槽數量 ``` 4. 為新的master新增從節點 - 再次啟動一個新的例項 - 新增至叢集並指定為某master的slave ```shell ./redis-cli --cluster add-node 10.211.55.9:7008 10.211.55.9:7001 --cluster-slave --cluster-master-id cda3828e42e23dcbdb141db2fed221bc07c59f65 #--cluster-slave 指定新節點作為slave #--cluster-master-id 指定新節點的master ``` ## 刪除節點 1. 刪除從節點7008 ```shell ./redis-cli --cluster del-node 10.211.55.9:7008 887d2f115f6a94bda86863576d73a131f12229d5 #指定叢集host:port 和要刪除的節點id ``` 2. 將主節點的雜湊槽分配給其他的主節點 ```shell /redis-cli --cluster reshard 10.211.55.9:7001 --cluster-from cda3828e42e23dcbdb141db2fed221bc07c59f65 --cluster-to cc2e48268ccdd52d1c7840c8f9d2d7f15cc74c1b ``` 3. 刪除主節點 ```shell ./redis-cli --cluster del-node 10.211.55.9:7007 887d2f115f6a94bda86863576d73a131f12229d5 #指定叢集host:port 和要刪除的節點id ``` 4. 雜湊槽均衡,該操作檢查各節點的槽均衡情況,若差異較大則自動重新分配 ```shell ./redis-cli --cluster rebalance 10.211.55.9:7001