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的主從復制原理是理解更為復雜的集群特性的基礎。