之前講了redis的持久化，持久化保證了即使 redis 服務重啓也不會丟失數據，因爲 redis 服務重啓後會將硬盤上持久化的數據恢復到內存中，但是當 redis 服務器的硬盤損壞了可能會導致數據丟失，如果通過 redis 的主從複製機制就可以避免這種’單點故障’。
Redis主從複製
主從複製：主節點負責寫數據，從節點負責讀數據，主節點定期把數據同步到從節點保證數據的一致性
Redis主從拓撲：
1.一主一從：用於主節點故障轉移從節點，當主節點的“寫”命令併發高且需要持久化，可以只在從節點開啓AOF（主節點不需要），這樣即保證了數據的安全性，也避免持久化對主節點的影響
2.一主多從：針對“讀”較多的場景，“讀”由多個從節點來分擔，但節點越多，主節點同步到多節點的次數也越多，影響帶寬，也加重主節點的穩定
3.樹狀主從：一主多從的缺點（主節點推送次數多壓力大）可用些方案解決，主節點只推送一次數據到從節點B，再由從節點B推送到C，減輕主節點推送的壓力。
主 redis 中的數據有多個個副本（replication）即從 redisB和從 redisC等，即使一臺 redis 服務器宕機其它多臺 redis 服務也可以繼續提供服務。
主從複製不會阻塞 master，在同步數據時，master 可以繼續處理 client 請求。
一個 redis 可以即是主又是從。
主從複製原理
數據同步
主從複製過程:
redis 2.8版本以上使用psync命令完成同步，過程分“全量”與“部分”複製
全量複製（完整複製）：一般用於初次複製場景（第一次建立SLAVE後全量）
複製過程說明：
slave 服務啓動，slave 會建立和 master 的連接，發送 sync 命令。
master 啓動一個後臺進程將數據庫快照保存到 RDB 文件中
注意：此時如果生成 RDB 文件過程中存在寫數據操作會導致 RDB 文件和當前主 redis 數據不一致，所以此時 master 主進程會開始收集寫命令並緩存起來。
master 就發送 RDB 文件給 slave
slave 將文件保存到磁盤上，然後加載到內存恢復
master 把緩存的命令轉發給 slave
注意：後續 master 收到的寫命令都會通過開始建立的連接發送給 slave。
當 master 和 slave 的連接斷開時 slave 可以自動重新建立連接。如果 master 同時收到多個 slave 發來的同步連接命令，只會啓動一個進程來寫數據庫鏡像，然後發送給所有 slave。
完整複製的問題：
在 redis2.8 之前從 redis 每次同步都會從主 redis 中複製全部的數據，如果從 redis 是新創建的從主 redis 中複製全部的數據這是沒有問題的，但是，如果當從 redis 停止運行，再啓動時可能只有少部分數據和主 redis 不同步，此時啓動 redis 仍然會從主 redis 複製全部數據，這樣的性能肯定沒有隻複製那一小部分不同步的數據高。
部分複製：網絡出現問題，從節點再次連接主節點時，主節點補發缺少的數據，每次數據增量同步
部分複製說明：
從機連接主機後，會主動發起 PSYNC 命令，從機會提供 master 的 runid(機器標識，隨機生成的一個串) 和 offset（數據偏移量，如果offset主從不一致則說明數據不同步），主機驗證 runid 和 offset 是否有效，runid 相當於主機身份驗證碼，用來驗證從機上一次連接的主機，如果 runid 驗證未通過則，則進行全同步，如果驗證通過則說明曾經同步過，根據 offset 同步部分數據。
心跳：主從有長連接心跳，主節點默認每10S向從節點發ping命令，repl-ping-slave-period控制發送頻率.
主從的缺點
1)主從複製，若主節點出現問題，則不能提供服務，需要人工修改配置將從變主
2)主從複製主節點的寫能力單機，能力有限
3)單機節點的存儲能力也有限
主從故障如何故障轉移
1)主節點(master)故障，從節點slave-1端執行 slaveof no one後變成新主節點；
2)其它的節點成爲新主節點的從節點，並從新節點複製數據；
3)需要人工干預，無法實現高可用。
因爲主從複製的缺陷無法實現高可用性，所以接下來會講到高可用的哨兵機制。
Redis哨兵機制（Sentinel）
哨兵機制的出現是爲了解決主從複製的缺點的
哨兵機制(sentinel)的高可用
原理：當主節點出現故障時，由Redis Sentinel自動完成故障發現和轉移，並通知應用方，實現高可用性。
其實整個過程只需要一個哨兵節點來完成，首先使用Raft算法（選舉算法）實現選舉機制，選出一個哨兵節點(來當主人master)完成轉移和通知。
哨兵的定時監控任務
任務1：每個哨兵節點每10秒會向主節點和從節點發送info命令獲取最拓撲結構圖，哨兵配置時只要配置對主節點的監控即可，通過向主節點發送info，獲取從節點的信息，並當有新的從節點加入時可以馬上感知到
任務2：每個哨兵節點每隔2秒會向redis數據節點的指定頻道上發送該哨兵節點對於主節點的判斷以及當前哨兵節點的信息，同時每個哨兵節點也會訂閱該頻道，來了解其它哨兵節點的信息及對主節點的判斷，其實就是通過消息publish和subscribe來完成的
任務3：每隔1秒每個哨兵會向主節點、從節點及其餘哨兵節點發送一次ping命令做一次心跳檢測，這個也是哨兵用來判斷節點是否正常的重要依據
客觀下線：當主觀下線的節點是主節點時，此時該哨兵3節點會通過指令sentinel is-masterdown-by-addr尋求其它哨兵節點對主節點的判斷，當超過quorum（選舉）個數，此時哨兵節點則認爲該主節點確實有問題，這樣就客觀下線了，大部分哨兵節點都同意下線操作，也就說是客觀下線
領導者哨兵選舉流程
1)每個在線的哨兵節點都可以成爲領導者，當它確認（比如哨兵3）主節點下線時，會向其它哨兵發is-master-down-by-addr命令，徵求判斷並要求將自己設置爲領導者，由領導者處理故障轉移；
2)當其它哨兵收到此命令時，可以同意或者拒絕它成爲領導者；
3)如果哨兵3發現自己在選舉的票數大於等於num(sentinels)/2+1時，將成爲領導者，如果沒有超過，繼續選舉…………
故障轉移機制
1)由Sentinel節點定期監控發現主節點是否出現了故障
sentinel會向master發送心跳PING來確認master是否存活，如果master在“一定時間範圍”內不迴應PONG 或者是回覆了一個錯誤消息，那麼這個sentinel會主觀地(單方面地)認爲這個master已經不可用了
2)當主節點出現故障，此時3個Sentinel節點共同選舉了Sentinel3節點爲領導，負載處理主節點的故障轉移
3) 由Sentinel3領導者節點執行故障轉移，過程和主從複製一樣，但是自動執行
流程：
1. 將slave-1脫離原從節點，升級主節點，
2. 將從節點slave-2指向新的主節點
3. 通知客戶端主節點已更換
4. 將原主節點（oldMaster）變成從節點，指向新的主節點
4)故障轉移後的redis sentinel的拓撲結構圖
哨兵機制－故障轉移詳細流程-確認主節點
-
過濾掉不健康的（下線或斷線），沒有回覆過哨兵ping響應的從節點
-
選擇salve-priority從節點優先級最高（redis.conf）的
-
選擇複製偏移量最大，指複製最完整的從節點
希望這些理論知識能給大家帶來一些幫助。接下來的博客會將到怎麼樣具體實現redis的主從複製（讀寫分離）和哨兵機制。
redis----實現數據庫服務器的高可用
nginx----實現應用服務器(tomcat)的高可用