主從複製:主節點負責寫數據,從節點負責讀數據,主節點按期把數據同步到從節點保證數據的一致性html
(1)配置文件:在從服務器的配置文件中加入 slaveof<masterip><masterport>。例如,新增redis6360.conf, 打開redis6360.conf並加入 slaveof 192.168.152.128 6359, 在6359啓動完後再啓6360,完成配置;前端
(2)啓動命令:redis-server啓動命令後加入 --slaveof<masterip><masterport>。例如,redis-server --slaveof 192.168.152.128 6359 臨時生效redis
(3)查看狀態:經過 info replication 命令能夠看到複製的一些信息。數據庫
(4)斷開主從複製:在slave節點,執行6380:>slaveof no one服務器
(5)斷開後再變成主從複製:6360:> slaveof 192.168.152.128 6359網絡
(6)數據較重要的節點,主從複製時使用密碼驗證: requirepass架構
主從複製過程大致能夠分爲3個階段:鏈接創建階段(即準備階段)、數據同步階段、命令傳播階段。併發
在從節點執行 slaveof 命令後,複製過程便開始運做,下面圖示能夠看出複製過程大體分爲6個過程。負載均衡
執行 slaveof 後 Redis 會打印以下日誌:less
從節點(slave)內部經過每秒運行的定時任務維護複製相關邏輯,當定時任務發現存在新的主節點後,會嘗試與該節點創建網絡鏈接。
從節點與主節點創建網絡鏈接。
從節點會創建一個 socket 套接字,從節點創建了一個端口爲51234的套接字,專門用於接受主節點發送的複製命令。從節點鏈接成功後打印以下日誌:
若是從節點沒法創建鏈接,定時任務會無限重試直到鏈接成功或者執行 slaveofnoone 取消複製。
關於鏈接失敗,能夠在從節點執行 info replication 查看 master_link_down_since_seconds 指標,它會記錄與主節點鏈接失敗的系統時間。從節點鏈接主節點失敗時也會每秒打印以下日誌,方便發現問題:
鏈接創建成功後從節點發送 ping 請求進行首次通訊, ping 請求主要目的以下:
檢測主從之間網絡套接字是否可用。
檢測主節點當前是否可接受處理命令。
若是發送 ping 命令後,從節點沒有收到主節點的 pong 回覆或者超時,好比網絡超時或者主節點正在阻塞沒法響應命令,從節點會斷開復制鏈接,下次定時任務會發起重連。
從節點發送的 ping 命令成功返回,Redis 打印以下日誌,並繼續後續複製流程:
若是主節點設置了 requirepass 參數,則須要密碼驗證,從節點必須配置 masterauth 參數保證與主節點相同的密碼才能經過驗證。若是驗證失敗複製將終止,從節點從新發起復制流程。
主從複製鏈接正常通訊後,對於首次創建複製的場景,主節點會把持有的數據所有發送給從節點,這部分操做是耗時最長的步驟。
當主節點把當前的數據同步給從節點後,便完成了複製的創建流程。接下來主節點會持續地把寫命令發送給從節點,保證主從數據一致性。
Redis支持主從複製,Redis的主從結構能夠採用一主多從或者級聯結構,Redis主從複製能夠根據是不是全量分爲全量同步和增量同步。下圖爲級聯結構。
Redis全量複製通常發生在Slave初始化階段,這時Slave須要將Master上的全部數據都複製一份。具體步驟以下:
- 從服務器配置主服務器的鏈接信息(slaveof屬性);
- 從服務器鏈接上主服務器,發送SYNC命令
- 主服務器判斷是否爲全量複製:若是是全量複製,則進入下一步;不然能夠看增量複製的子流程。
- 主服務器接收到SYNC命名後,開始執行BGSAVE命令生成RDB文件並使用緩衝區記錄此後執行的全部寫命令;
- 主服務器BGSAVE執行完後,向全部從服務器發送快照文件,並在發送期間繼續記錄被執行的寫命令;
- 從服務器收到快照文件後丟棄全部舊數據,載入收到的快照;
- 主服務器快照發送完畢後開始向從服務器發送緩衝區中的寫命令;
- 從服務器完成對快照的載入,開始接收命令請求,並執行來自主服務器緩衝區的寫命令;
Redis增量複製是指Slave初始化後開始正常工做時主服務器發生的寫操做同步到從服務器的過程。
增量複製的過程主要是主服務器每執行一個寫命令就會向從服務器發送相同的寫命令,從服務器接收並執行收到的寫命令。
主從剛剛鏈接的時候,進行全量同步;全同步結束後,進行增量同步。固然,若是有須要,slave 在任什麼時候候均可以發起全量同步。redis 策略是,不管如何,首先會嘗試進行增量同步,如不成功,要求從機進行全量同步。
(1)數據冗餘:主從複製實現了數據的熱備份,是持久化以外的一種數據冗餘方式。
(2)故障恢復:當主節點出現問題時,能夠由從節點提供服務,實現快速的故障恢復;其實是一種服務的冗餘。
(3)負載均衡:在主從複製的基礎上,配合讀寫分離,能夠由主節點提供寫服務,由從節點提供讀服務(即寫Redis數據時應用鏈接主節點,讀Redis數據時應用鏈接從節點),分擔服務器負載;尤爲是在寫少讀多的場景下,經過多個從節點分擔讀負載,能夠大大提升Redis服務器的併發量。
(4)讀寫分離:能夠用於實現讀寫分離,主庫寫、從庫讀,讀寫分離不只能夠提升服務器的負載能力,同時可根據需求的變化,改變從庫的數量。
(5)高可用基石:除了上述做用之外,主從複製仍是哨兵和集羣可以實施的基礎,所以說主從複製是Redis高可用的基礎。
a.同一個Master能夠同步多個Slaves。
b.Slave一樣能夠接受其它Slaves的鏈接和同步請求,這樣能夠有效的分載Master的同步壓力。所以咱們能夠將Redis的Replication架構視爲圖結構。
c.Master Server是以非阻塞的方式爲Slaves提供服務。因此在Master-Slave步期間,客戶端仍然能夠提交查詢或修改請求。
d.Slave Server一樣是以非阻塞的方式完成數據同步。在同步期間,若是有客戶端提交查詢請求,Redis則返回同步以前的數據。
e.爲了分載Master的讀操做壓力,Slave服務器能夠爲客戶端提供只讀操做的服務,寫服務仍然必須由Master來完成。即使如此,系統的伸縮性仍是獲得了很大的提升。
f.Master能夠將數據保存操做交給Slaves完成,從而避免了在Master中要有獨立的進程來完成此操做。
g.支持主從複製,主機會自動將數據同步到從機,能夠進行讀寫分離。
a.Redis不具有自動容錯和恢復功能,主機從機的宕機都會致使前端部分讀寫請求失敗,須要等待機器重啓或者手動切換前端的IP才能恢復。
b. 主機宕機,宕機前有部分數據未能及時同步到從機,切換IP後還會引入數據不一致的問題,下降了系統的可用性。
c. Redis的主從複製採用全量複製,複製過程當中主機會fork出一個子進程對內存作一份快照,並將子進程的內存快照保存爲文件發送給從機,這一過程須要確保主機有足夠多的空餘內存。若快照文件較大,對集羣的服務能力會產生較大的影響,並且複製過程是在從機新加入集羣或者從機和主機網絡斷開重連時都會進行,也就是網絡波動都會形成主機和從機間的一次全量的數據複製,這對實際的系統運營形成了不小的麻煩。
d. Redis較難支持在線擴容,在集羣容量達到上限時在線擴容會變得很複雜。爲避免這一問題,運維人員在系統上線時必須確保有足夠的空間,這對資源形成了很大的浪費。
Redis在與從數據庫進行復制初始化時將不會將快照存儲到磁盤,而是直接經過網絡發送給從數據庫,避免了IO性能差問題。
啓無磁盤複製:repl-diskless-sync yes
http://www.zhuanzhi.ai/document/1e2a07d1b7d0c822d01039d808db2f1d
http://www.elecfans.com/d/883975.html
http://www.codedocs.net/blog/477
https://www.cnblogs.com/PatrickLiu/p/8426610.html
https://www.cnblogs.com/leeSmall/p/8398401.html
https://www.cnblogs.com/wdliu/p/9407179.html
https://www.cnblogs.com/kevingrace/p/5685332.html