redis主從複製

1.redis主從複製的作用

　　redis的定位是一個高可用的數據伺服器，可是在實際生產環境下，單機的redis伺服器是無法滿足真正意義上的高可用性的。

　　第一，單機的redis伺服器很容易發生單點故障，即使redis提供了各種持久化的方法來避免數據的丟失，但是物理上的故障(硬碟損毀等)還是無法完全避免的。

　　第二，如果對單台機器的性能進行縱向拓展，無論是CPU，記憶體還是磁碟容量都很容易達到瓶頸，無法滿足實際需求。

　　針對這些問題，redis提供了複製(replication)的功能，通過"主從(一主多從)"和"集群(多主多從)"的方式對redis的服務進行水平擴展,用多台redis伺服器共同構建一個高可用的redis服務系統。

　　在這裡，我們主要介紹redis的主從複製功能。

2.redis主從複製介紹　　

　　在redis的複製概念模型中，分為"主(master)"和"從(slave)"兩種角色類型的伺服器，從伺服器"服從"主伺服器。主伺服器既可以讀也可以寫，而從伺服器原則上只允許讀操作(通過修改配置，從伺服器也可以執行寫入操作)，同時負責接收和同步主伺服器上的數據。主伺服器和從伺服器是一對多的關係，從伺服器也可以擁有從伺服器，以此類推。　　

　　可以看到主從結構下的redis伺服器集群節點的拓撲結構是一棵樹。

　　使用了主從結構的redis系統，一般是讀寫分離的："主庫負責寫入，在寫入的同時和從庫進行數據的同步；而從庫負責讀取操作。"

　　一主多從的結構下，不會出現單點故障，同時可用性也得到了保障。由於負責讀取的從庫相對較多，因此很適合讀多寫少(例如:電商)的場景。

　　使用redis的主從複製功能比較簡單，只需要在從伺服器啟動的配置文件中添加slaveof "IP" "PORT"配置即可，同時redis也允許其它的方式來實現這一目的(啟動時命令行參數、redis命令等)。可以通過info replication來查看當前redis伺服器在主從複製中的狀態。

　　　　6381埠 從庫狀態

　　  6379埠 主庫狀態

3.redis主從複製原理　　

　　1.從伺服器初始化

　　當從伺服器啟動時，會向主伺服器發送SYNC命令，請求同步數據。主伺服器接收到消息之後，進行RDB持久化，並生成一個快照文件；與此同時，主伺服器會將生成快照期間新執行的命令緩存起來。在快照文件生成完畢之後，主伺服器將RDB快照文件和緩存下來的命令一併發送給從伺服器，從伺服器首先載入接收到的RDB快照文件，接著執行被緩存下來的新命令，完成主從數據的初始化同步操作。

　　2.從伺服器保持同步

　　從伺服器在同步完成之後，主伺服器接收到的所有命令都會非同步的發送給從伺服器用來保持主從數據的一致性。

　　3.從伺服器故障後處理

　　當從伺服器崩潰之後，重啟之後進行初始化，會自動的同步主伺服器的數據。在redis的2.8版本之後，redis採用了"增量複製"的方式優化了從伺服器的初始化同步數據的過程。

　　4.主伺服器故障後處理

　　當主伺服器崩潰之後，首先需要手動的選擇一個從伺服器升級為主伺服器(需要手動調整所有相關的從伺服器)，然後啟動之前已經崩潰的主伺服器作為從伺服器回到系統中。

　　可以看到，redis在主伺服器崩潰之後需要繁瑣的人工干預來恢復服務，特別是在主資料庫禁止了持久化之後，上述步驟不能錯亂，否則會導致主資料庫重啟後恢復了錯誤數據，進而導致從資料庫也同步錯誤數據這一災難性後果。為此，redis提供了哨兵機制，用於自動化的監控和維持分散式redis系統的良好運轉。

4.redis哨兵

　　1.哨兵的介紹　　

　　redis的設計者為了讓redis能夠在主從模式下實現故障恢復的自動化，為此提供了redis的哨兵功能。哨兵是一個獨立於數據伺服器的進程，用於監控redis數據伺服器的狀態，當主從模式下最關鍵的主伺服器出現故障時，能夠被哨兵自動的察覺。同時哨兵會在剩餘的從伺服器中"選舉"出新的主伺服器，達到自動化恢復系統服務的目的。

 　　2.哨兵的使用

　　redis提供了redis-sentinel腳本用於部署哨兵，啟動時通過指定的哨兵配置文件來對哨兵的行為進行靈活的控制。哨兵的配置文件中至少需要包含被哨兵監控的主伺服器IP、埠、投票決定數目，當然也可以配置諸如down-after-milliseconds(發送ping命令的時間間隔，用於監聽)等選項。

　　sentinel monitor "master_name" "IP" "PORT"　

　　down-after-milliseconds "milliseconds"　("milliseconds"大於1000時，預設為1000)

　　3.哨兵的工作方式

　　哨兵啟動時會與主伺服器建立連接，並且間接的獲得所屬從伺服器信息，完成哨兵的初始化。哨兵初始化完成之後，會周期性的和主從伺服器、其它哨兵節點(通過消息頻道的訂閱/發佈)進行通信。

　　哨兵每10秒會向所有伺服器發送一次INFO命令，獲得相關redis伺服器的當前狀態以便決定是否需要故障恢復。

　　當一個哨兵在down-after-milliseconds規定時間內未收到主伺服器的響應，則當前哨兵"主觀"認為主伺服器下線，同時和監視當前系統的其它哨兵進行投票決定，當超過當前哨兵配置中投票決定的數目時，則當前哨兵"客觀"認為主伺服器下線，哨兵集群會選舉出領導哨兵來進行主從伺服器集群主從狀態的切換(使用Raft演算法)。

5.redis主從複製總結

　　1.樂觀複製策略

　　redis的主從複製採用的是樂觀複製的策略，在一定的時間內允許主從伺服器的數據不完全一致，但是保持主從資料庫數據的最終一致性(按照CAP定理,放棄了C(強一致性))。

　　這意味著redis主從伺服器之間的數據複製操作時非同步的，主伺服器不等待從伺服器返回覆制的結果，可以立即處理新的寫入命令。這一策略使得主伺服器的性能在複製時不會受到太大影響，但是從伺服器會出現短時間內數據不一致的情況。redis允許用戶配置主庫的min-slaves-to-write(代表至少N台從伺服器完成複製，才允許主伺服器寫入)和min-slaves-max-lag(允許從伺服器斷開連接的時間)這兩個配置項來控制分區中數據不一致的影響。

　　2.和集群的區別

　　redis的主從複製特性為redis帶來了很高的讀取可用性，但是對於海量數據的持久化存儲是力不從心的。因為主從複製結構下，任意的節點都保存了100%的存儲數據，所以能夠存儲的數據規模還是受限於單例伺服器存儲容量的大小。

　　為此，在單主多從結構的基礎上，redis還提供了集群特性。通過將存儲數據合理的分片存儲在不同的redis節點上，通過集群水平擴容之後的redis集群擁有了極高的讀寫可用性和分區容錯性。為了理解更強大、複雜的集群特性其基礎之一就是redis的主從複製原理。