Redis詳解(五)——主從複製
面臨問題
- 機器故障。咱們部署到一臺 Redis 服務器,當發生機器故障時,須要遷移到另一臺服務器而且要保證數據是同步的。而數據是最重要的,若是你不在意,基本上也就不會使用 Redis 了。
- 容量瓶頸。當咱們有需求須要擴容 Redis 內存時,從 16G 的內存升到 64G,單機確定是知足不了。固然,你能夠從新買個 128G 的新機器。
解決辦法
要實現分佈式數據庫的更大的存儲容量和承受高併發訪問量,咱們會將原來集中式數據庫的數據分別存儲到其餘多個網絡節點上。redis
Redis 爲了解決這個單一節點的問題,也會把數據複製多個副本部署到其餘節點上進行復制,實現 Redis的高可用,實現對數據的冗餘備份,從而保證數據和服務的高可用。數據庫
主從複製
什麼是主從複製
主從複製,是指將一臺Redis服務器的數據,複製到其餘的Redis服務器。前者稱爲主節點(master),後者稱爲從節點(slave),數據的複製是單向的,只能由主節點到從節點。服務器
默認狀況下,每臺Redis服務器都是主節點;且一個主節點能夠有多個從節點(或沒有從節點),但一個從節點只能有一個主節點。網絡
主從複製的做用
- 數據冗餘:主從複製實現了數據的熱備份,是持久化以外的一種數據冗餘方式。
- 故障恢復:當主節點出現問題時,能夠由從節點提供服務,實現快速的故障恢復;其實是一種服務的冗餘。
- 負載均衡:在主從複製的基礎上,配合讀寫分離,能夠由主節點提供寫服務,由從節點提供讀服務(即寫Redis數據時應用鏈接主節點,讀Redis數據時應用鏈接從節點),分擔服務器負載;尤爲是在寫少讀多的場景下,經過多個從節點分擔讀負載,能夠大大提升Redis服務器的併發量。
- 讀寫分離:能夠用於實現讀寫分離,主庫寫、從庫讀,讀寫分離不只能夠提升服務器的負載能力,同時可根據需求的變化,改變從庫的數量;
- 高可用基石:除了上述做用之外,主從複製仍是哨兵和集羣可以實施的基礎,所以說主從複製是Redis高可用的基礎。
主從複製啓用
從節點開啓主從複製,有3種方式:併發
- 配置文件: 在從服務器的配置文件中加入:slaveof <masterip> <masterport>
- 啓動命令: redis-server啓動命令後加入 --slaveof <masterip> <masterport>
- 客戶端命令: Redis服務器啓動後,直接經過客戶端執行命令:slaveof <masterip> <masterport>,則該Redis實例成爲從節點。
主從複製原理
主從複製過程大致能夠分爲3個階段:鏈接創建階段(即準備階段)、數據同步階段、命令傳播階段。負載均衡
創建鏈接階段
數據同步階段
注意:分佈式
master高併發
- 若是master數據量巨大,數據同步階段應避開流量高峯期,避免形成master阻塞,影響業務正常進行。
- 複製緩衝區大小設定不合理,會致使數據益處。如進行全量複製週期太長,進行部分複製時發現數據已經存在丟失狀況,必須進行第二次全量複製,知識slave陷入死循環。
- master單機內存佔用主機內存的比例不該過大,建議使用50%-70%,留下30%-50%的內存用於執行bgsave命令和建立複製緩衝區
slaveserver
- 爲了不slave進行全量複製、部分複製時服務器響應阻塞或數據不一樣步,建議關閉此期間對外服務
- 多個slave同時對master請求數據同步,master發送的RDB文件會增多,會對帶寬形成巨大沖擊,若是master帶寬不足,所以數據同步須要根據業務需求,適量錯峯
- slave過多時,建議調整拓撲結構,由一主多從結構變爲樹狀結構,中間的節點即時master,也是slave。注意使用樹狀結構時,因爲層級深度,致使深度越高的slave與最頂層master間數據同步延遲較大,數據一致性變差,應謹慎選擇
命令傳播階段
服務器運行ID(runid)blog
- 概念:服務器運行ID是每一臺服務器每次運行的身份識別碼,一臺服務器屢次運行能夠生成多個運行ID
- 組成:運行ID由40位字符組成,是一個隨機的16進制字符
- 做用:運行ID被用於在服務器間進行傳輸,識別身份。若是想兩次操做均對同一臺服務器進行,必須每次操做攜帶對應的運行ID,用於對方識別
- 實現方式:運行ID在每臺服務器啓動時自動生成,master首次鏈接slave時,會將本身的運行id發送給slave,slave保存 此ID。
設置複製緩衝區的大小
- 測算從master到slave的重連平均時長second
- 獲取master平均每秒產生寫命令數據總量write_size_per_second
- 最優複製緩衝區大小 = 2 * write_size_per_second
心跳機制