Redis應用學習（六）——主從複製

1. 認識主從複製

    1. 單機部署Redis的問題：首先是若是機器故障（忽然斷電或者機器宕機），那麼數據就會大量丟失；其次就是單機Redis的容量會有瓶頸，受限於機器的內存空間；每秒的請求處理數也會受到單機Redis的限制，儘管Redis每秒的請求處理數能夠很高，但在大型應用中仍然是遠遠不夠的。爲了解決這些問題，實現高可用，Redis提供了一個主從複製的功能，來實現集羣式部署Redis

    2. 簡單瞭解主從複製的模型：主從複製，會有一個主節點和多個從節點，每個節點都是一個Redis，並且每個Redis節點都能給客戶端提供Redis的服務，主從複製就是從主Redis節點中複製數據到從Redis節點，若是主節點進行一個數據更新操做，那麼從節點也會進行一個相同的操做。主從複製經過RDB文件來實現。

    3. 主從複製的做用：

• 數據副本：避免單機部署中機器故障形成的數據丟失，並且若是主節點宕機，從節點就會提供支援代替主節點向客戶端提供服務。
• 擴展性能：讀寫操做分離，大量的對主節點進行讀寫操做會形成很大的性能負擔，能夠將讀操做分流到多個從節點中，這樣就能夠極大的提高讀操做的性能。

    4. 主從複製的特色：

• 只能一個主節點對於多個從節點，一對多的關係
• 數據只能從主節點複製到從節點，數據流是單向的

2. 主從複製的實現配置

    1. 有兩種實現方式：分別是經過運行命令來實現，另外一種是經過redis的啓動配置文件來實現

• slaveof命令：
  • 變爲從節點：使用形式爲slaveof  masterip masterport，須要指定當前從節點Redis的主節點Redis的ip地址masterip和端口號masterport，執行該命令後，就會經過網絡鏈接到指定的主節點，並經過網絡傳輸進行數據複製，數據複製是異步操做；另外，若是從節點中以前存儲有數據，那麼在變成從節點以後就會清空以前保存的數據
  • 變爲主節點：使用形式爲slaveof  no one，會取消本身與主節點的主從關係，但不會刪除以前複製的數據
• 經過從節點Redis的啓動配置文件修改配置參數：
  • slaveof  masterip masterport：須要指定主節點Redis所在機器的IP地址masterip 和運行時佔用的端口號masterport
  • slave-read-only yes：該配置參數表示當前從節點是否只容許進行讀操做，默認yes表示只能進行讀操做（不建議修改），該配置參數保證了當前Redis節點被配置爲從節點以後，不會執行寫操做，防止主從節點之間的數據不一樣步

3. 主從複製的實現方式——全量複製功能

    1. run_id：Redis每次啓動時，都會生成一個不一樣的id來標示當前運行的Redis。從節點中會保存主節點的run_id標示，若是主節點的Redis發生了重啓，那麼從節點依據ip和端口號鏈接到主節點時，就會發現主節點的run_id標示的改變（這種改變意味着主節點中的數據可能發生的大量的改動），因此此時就會引發全量複製，也就是將主節點中的全部數據所有複製過來。

    2. 偏移量：每當主節點增刪改一個數據時，主節點中就會有一個數值來記錄這種變化，偏移量就是記錄Redis中數據改變的一個標示，當主節點更改一個數據時，偏移量也會發生對應的改變，並且主節點在將數據更改命令同步給從節點時，也會將該偏移量發送給從節點，這樣就能夠對比主從節點的偏移量，來觀察是否出現主從不一致的問題。下圖中master_repl_offset就表示主節點的偏移量，高亮處就表示從節點中的偏移量，使用 ./redis-cli -p 6379 info replication 該命令便可在主節點中查看主從節點的偏移量

    3. 全量複製：全量複製指的是不只僅複製主節點發送過來的RDB文件中的數據，還要將主節點在生成RDB文件期間主節點後續執行的數據更改命令所更改的數據一併複製過來，在這期間，主節點執行的數據更改命令會被記錄在一個緩衝區repl_back_buffer中，當從節點RDB加載完畢後，就會將這一部分被更改的數據同步到從節點中，具體過程以下

• 當從節點執行slaveof命令時，就會自動向主節點發送一條命令(psync ? -1)，第一個參數表示主節點的run_id，第二個參數表示當前從節點的偏移量爲-1，而後從節點就會接收到主節點返回的主節點的run_id和偏移量等信息並保存
• 主節點自動執行bgsave命令生成RDB文件，在此期間會記錄後續執行的數據更改命令所更改的數據，直到主節點將生成的RDB文件傳輸到從節點爲止
• 主節點發送RDB文件，從節點接收完畢後，主節點會將緩衝區中記錄的新更改的數據發送給從節點，從節點再接收
• 從節點清空此前的全部數據，加載RDB文件恢復數據並存入新更改的數據

    4. 全量複製的性能開銷：主要消耗在主節點RDB文件的生成須要的時間，其次是RDB文件在網絡間的傳輸時間，還須要從節點的數據清空時間、加載RDB文件的時間

    5. 數據更改命令緩衝區repl_back_buffer用於：當Redis經過Linux中的fork()函數開闢一個子進程處理其餘事務（好比主進程執行bgsave生成一個RDB文件時，或者主進程執行bgrewriteaof生成一個AOF文件時），而主進程（即處理客戶端命令的進程）後續執行的一些數據更改命令會被暫時保存在該區域，並且該區域空間有限（配置文件中repl-backlog-size 1mb便可配置該處空間大小）

4. 主從複製的實現方式——部分複製功能

    1. 部分複製解決的問題：在實際環境中，主節點與從節點之間可能會發生一些網絡波動等狀況，致使從節點與主節點之間的網絡鏈接斷開（主從節點的Redis均未關閉），若是從新鏈接上後，可使用全量複製來從新進行一次主從節點數據同步，可是全量複製會帶來一個性能開銷的問題，並且從節點中可能有大量數據是主節點中沒有更該過的，也就是不須要進行再次同步的數據，若是使用全量複製確定是帶來了一些沒必要要的浪費。因此，部分複製功能就是爲了解決該問題的。

    2. 部分複製的發生過程：

• 主從節點直接鏈接斷開，此時主節點繼續執行的數據更改命令會被記錄在一個緩衝區repl_back_buffer中
• 當從節點從新鏈接主節點時，就會自動發出一條命令(psync offset runid)，將從節點中存儲的主節點的Redis運行時id和從節點中保存的偏移量發送給主節點
• 主節點接收從節點發送的偏移量和id，對比此時主節點的偏移量和接收的偏移量，若是兩個偏移量之差大於repl_back_buffer中的數據，那麼就表示在斷開鏈接期間從節點已經丟失了超出規定數量的數據，此時就須要進行全量複製了，不然就進行部分複製
• 將主節點緩衝區中的數據同步更新到從節點中，這樣就實現了部分數據的複製同步，下降了性能開銷

5. 主從節點之間的故障維護

    1. 故障發生時服務自動轉移（自動故障轉移）：即當某個節點發生故障致使中止服務時，該節點提供的服務會有另外一個節點自動代替提供，這樣就實現了一個高可用的效果

    2. 從節點故障：即若是某個從節點發生了故障，致使沒法向在該節點上的客戶端提供讀服務，解決辦法就是使該客戶端轉移到另外一個可用從節點上，可是在轉移時，應該考慮該從節點能承受幾個客戶端的壓力

    3. 主節點故障：若是主節點發生故障，在使用主節點進行讀寫操做的客戶端就沒法使用了，而使用從節點只進行讀操做的客戶端仍是能夠繼續使用的，解決辦法就是從從節點中選一個節點更改成主節點，而且將原主節點的客戶端鏈接到新的主節點上，而後經過該客戶端將其餘從節點鏈接到新的主節點中

    4. 主從複製確實能夠解決故障問題，可是主從複製不能實現自動故障轉移，其必需要經過一些手動操做，並且很是麻煩，因此要實現自動故障轉移還須要另外一個功能，Redis中提供了sentinel功能來實現自動故障轉移。

6. 主從複製常見問題

    1. 讀寫分離：即客戶端發來的讀寫命令分開，寫命令交給主節點執行，讀命令交給從節點執行，不只減小了主節點的壓力，並且加強了讀操做的能力；但也會形成一些問題

• 可是主從節點之間數據複製形成的阻塞延遲也可能會致使主從不一致的狀況，也就是主節點先進行了寫操做，但可能由於數據複製形成的阻塞延遲，致使在從節點上進行的讀操做獲取的數據與主節點不一致
• 讀取過時數據：主從複製會將帶有過時時間的數據一併複製到從節點中，可是從節點是沒有刪除數據的能力的，即便是過時數據，因此主節點中的已經刪除了過時數據，可是由於主從複製的阻塞延遲問題致使從節點中的過時數據沒有刪除，此時客戶端就會讀到一個過時數據

    2. 主從配置不一致：形成的問題有

• 好比配置中的maxmemory參數若是配置不一致，好比主節點2Gb，從節點1Gb，那麼就可能會致使數據丟失；以及一些其餘配置問題

    3. 規避全量複製：全量複製的性能開銷較大，因此要儘可能避免全量複製，

• 在第一次創建主從節點關係式必定會發生全量複製；能夠適當減少Redis的maxmemory參數，這樣可使得RDB更快，或者選擇在客戶端操做低峯期進行，好比深夜
• 從節點中保存的主節點運行id不一致時也必定會發生全量複製（好比主節點的重啓）；能夠經過故障轉移來儘可能避免
• 當主從節點的偏移量之差大於命令緩衝區repl_back_buffer中對應數據的偏移差時，也會發生全量複製，也就是上面的部分複製的複製過程當中所說的；能夠增大配置文件中repl-backlog-size即數據緩衝區可儘可能避免

    4. 規避複製風暴：

• 單主節點致使的複製風暴，即當主節點重啓後，要向其全部的從節點都進行一次全量複製，這很是消耗性能；能夠更換主從節點的結果，更換爲相似樹形的結構，一個主節點只與少許的從節點創建主從關係，而而這些主節點又與其餘從節點構成主從關係，以下圖所示
• 單主節點機器複製風暴：即若是過一臺機器專門用來部署多個主節點，而後其餘機器部署從節點，那麼一旦主節點機器宕機重啓，就會引發全部的主從節點之間的全量複製，形成很是大的性能開銷；能夠採用多臺機器，分散部署主節點，或者使用自動故障轉移來將某個從節點變爲主節點實現一個高可用