(三)Redis主從複製介紹

1.什麼是主從複製

1.1 簡介

在分佈式環境中,數據副本 (Replica) 和複製 (Replication) 作爲提升系統可用性和讀寫性能的有效手段被大量應用系統設計中,Redis 也不例外。Redis 作爲單機數據庫使用時,適用常見有限且存在單點宕機問題,無法維持高可用。因此 Redis 允許通過 SLAVEOF 命令或者 slaveof 配置項來讓一個 Redis server 複製另一個 Redis server 的數據集和狀態,我們稱之爲主從複製,主服務器下文稱 master,從服務器下文稱 slave,Redis 採用異步的複製機制。

複製機制的運行依靠三個特性:

  1. 當一個 master 和一個 slave 連接正常時,master 會發送一連串的命令流來保持對 slave 的更新,以便於將自身數據集的變更復制給 slave :包括客戶端的寫入、key 的過期或被逐出等

  2. masterslave 之間的連接斷開後(斷開的原因可能是網絡問題或者連接超時) slave 重連上 master 並嘗試進行部分重同步,這意味着它只會嘗試獲取在斷開連接期間內丟失的命令流

  3. 當無法進行部分重同步時, slave 會請求進行全量重同步。這會涉及到一個更復雜的過程,例如 master 需要創建所有數據的快照,將之發送給 slave ,之後在數據集更改時持續發送命令流到 slave

1.2 主從複製的優點

  • master 可以關閉持久化機制,減少不必要的 IO 操作且降低延遲,對於以性能著稱的組件來說極爲重要

  • slave 雖然不能處理寫請求,但是可以處理讀請求,從而增加讀取操作的吞吐量。但由於複製機制的原因,主從數據存在不一致的時間窗口

  • 使得 Redis 可以告別單機版本的單點風險,採用副本形式提高可用性,在 master 宕機時可以將 slave 提升爲 master 繼續向外提供服務,也爲 Redis 集羣模式的誕生奠定了技術基礎

這裏需要注意的是 Redis 2.8 版本之前與之後採用的複製方式不盡相同,主要區別在將成本極高的 sync 替換爲 psync,增加了斷線重連情況下根據主從保存的 offset 即複製偏移量進行增量同步的功能。

1.3 主從複製的缺點

a)主從複製,若主節點出現問題,則不能提供服務,需要人工修改配置將從變主
b)主從複製主節點的寫能力單機,能力有限
c)單機節點的存儲能力也有限

1.4 主從複製和集羣

有時我們會混淆這兩個概念,主從複製也是採用了多個 Redis 節點,和 Redis 集羣表面上看很接近,那二者究竟有什麼區別呢?

Replication

複製機制中包含了一個 master 和若干個 slave,其中寫請求只能 master 來處理,數據的變更轉化爲數據流異步發送給 slaves 進行更新;讀請求則可以根據使用場景來規定是否由 slave 處理從而增加系統的讀吞吐量。一旦 master 發生故障,slave 可以被提升爲 master 從而繼續提供服務。因此總結起來,slave 在複製機制的場景下,可以提供故障恢復、分擔讀流量和數據備份的功能。

Cluster

集羣機制的使用意味着你的數據量較大,數據會根據 Key 計算出的 slot 值自動在多個分片上進行分區(Partitioning),客戶端對某個 Key 的請求會被轉發到持有那個 Key 的分片上。分片由一個 master 和若干個 slave 組成,二者間通過複製機制同步數據。因此總結來看,集羣模式更像分區和複製機制的組合。

2. 主從複製機制的演變

從 Redis 2.6 到 4.0 開發人員對複製流程進行逐步的優化,以下是演進過程:

  • 2.8 版本之前 Redis 複製採用 sync 命令,無論是第一次主從複製還是斷線重連後再進行復制都採用全量同步,成本高

  • 2.8 ~ 4.0 之間複製採用 psync 命令,這一特性主要添加了 Redis 在斷線重連時候可通過 offset 信息使用部分同步

  • 4.0 版本之後也採用 psync,相比於 2.8 版本的 psync 優化了增量複製,這裏我們稱爲 psync2,2.8 版本的 psync 可以稱爲 psync1

3. 主從複製的原理

主從複製過程可分爲三個階段:複製初始化、數據同步和命令傳播。

複製初始化階段

當執行完 slaveof 命令後,slave 根據指明的 master 地址向 master 發起 socket 連接,master 收到 socket 連接之後將連接信息保存,此時連接建立完成;當 socket 連接建立完成以後,slavemaster 發送 PING 命令,以確認 master 是否存活,此時的結果返回如果是 PONG 則代表 master 可用,否則可能出現超時或者 master 此時在處理其他任務阻塞了,那麼此時 slave 將斷開 socket 連接,然後進行重試;

如果 master 連接設置了密碼,則 slave 需要設置 masterauth 參數,此時 slave 會發送 auth 命令,命令格式爲 auth + 密碼 進行密碼驗證,其中密碼爲 masterauth 參數配置的密碼,需要注意的是如果 master 設置了密碼驗證,從庫未配置 masterauth 參數則會報錯,socket 連接斷開。當身份驗證完成以後,slave 發送自己的監聽端口,master 保存其端口信息,此時進入下一個階段:數據同步階段。

數據同步階段

masterslave 都確認對方信息以後,便可開始數據同步,此時 slave 向主庫發送 psync 命令(需要注意的是 redis 4.0 對 2.8 版本的 psync 做了優化),主庫收到該命令後判斷是進行增量同步還是全量同步,然後根據策略進行數據的同步,當 master 有新的寫操作時候,此時進入複製第三階段:命令傳播階段。

命令傳播階段

當數據同步完成以後,在此後的時間裏 master-slave 之間維護着心跳檢查來確認對方是否在線,每隔一段時間(默認10秒,通過 repl-ping-slave-period 參數指定)masterslave 發送 PING 命令判斷 slave 是否在線,而 slave 每秒一次向 master 發送 REPLCONF ACK 命令命令格式爲:REPLCONF ACK {offset} ,其中 offsetslave 保存的複製偏移量,作用有:

  • 彙報自己複製偏移量,master 會對比複製偏移量向 slave 發送未同步的命令

  • 判斷 master 是否在線

slave 接送命令並執行,最終實現與主庫數據相同

4.主從故障如何故障轉移

a)主節點(master)故障,從節點slave-1端執行 slaveof no one後變成新主節點;
b)其它的節點成爲新主節點的從節點,並從新節點複製數據;
c)需要人工干預,無法實現高可用。

5.Redis哨兵機制

1. 爲什麼要有哨兵機制?

       哨兵機制的出現是爲了解決主從複製的缺點的。

2. 哨兵機制(sentinel)的高可用

  原理:當主節點出現故障時,由Redis Sentinel自動完成故障發現和轉移,並通知應用方,實現高可用性。

其實整個過程只需要一個哨兵節點來完成,首先使用Raft算法(選舉算法)實現選舉機制,選出一個哨兵節點來完成轉移和通知。

3. 哨兵的定時監控任務

任務1:每個哨兵節點每10秒會向主節點和從節點發送info命令獲取最拓撲結構圖,哨兵配置時只要配置對主節點的監控即可,通過向主節點發送info,獲取從節點的信息,並當有新的從節點加入時可以馬上感知到

任務2:每個哨兵節點每隔2秒會向redis數據節點的指定頻道上發送該哨兵節點對於主節點的判斷以及當前哨兵節點的信息,同時每個哨兵節點也會訂閱該頻道,來了解其它哨兵節點的信息及對主節點的判斷,其實就是通過消息publish和subscribe來完成的

 任務3:每隔1秒每個哨兵會向主節點、從節點及其餘哨兵節點發送一次ping命令做一次心跳檢測,這個也是哨兵用來判斷節點是否正常的重要依據

客觀下線:當主觀下線的節點是主節點時,此時該哨兵3節點會通過指令sentinel is-masterdown-by-addr尋求其它哨兵節點對主節點的判斷,當超過quorum(選舉)個數,此時哨兵節點則認爲該主節點確實有問題,這樣就客觀下線了,大部分哨兵節點都同意下線操作,也就說是客觀下線

 

4. 領導者哨兵選舉流程

a)每個在線的哨兵節點都可以成爲領導者,當它確認(比如哨兵3)主節點下線時,會向其它哨兵發is-master-down-by-addr命令,徵求判斷並要求將自己設置爲領導者,由領導者處理故障轉移;
b)當其它哨兵收到此命令時,可以同意或者拒絕它成爲領導者;
c)如果哨兵3發現自己在選舉的票數大於等於num(sentinels)/2+1時,將成爲領導者,如果沒有超過,繼續選舉…………

 

5. 故障轉移機制

a)由Sentinel節點定期監控發現主節點是否出現了故障

sentinel會向master發送心跳PING來確認master是否存活,如果master在“一定時間範圍”內不迴應PONG 或者是回覆了一個錯誤消息,那麼這個sentinel會主觀地(單方面地)認爲這個master已經不可用了

 

 

 b) 當主節點出現故障,此時3個Sentinel節點共同選舉了Sentinel3節點爲領導,負載處理主節點的故障轉移

 

 c) 由Sentinel3領導者節點執行故障轉移,過程和主從複製一樣,但是自動執行

 

 流程:

    1. 將slave-1脫離原從節點,升級主節點,

         2. 將從節點slave-2指向新的主節點

         3. 通知客戶端主節點已更換

         4. 將原主節點(oldMaster)變成從節點,指向新的主節點

 d) 故障轉移後的redis sentinel的拓撲結構圖

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章