跟我一塊兒學Redis之高可用從主從複製開始

前言

如今遇到高併發場景時，緩存技術應該算是性能優化的第一步，緩解數據庫壓力的同時還能提升訪問效率，而Redis應該是絕大多數應用場景的首選。可是儘快Redis性能再優秀，在當今高併發場景下，一臺服務器負責讀寫，機器的性能和內存的瓶頸確定避免不了，到這確定有小夥伴會想到集羣， 對的，思路沒錯，只是在集羣以前，主從複製模式的優化策略能解決不少問題，若是主從模式還抗不住高併發，那再來集羣也不晚；這裏先來講說Redis的主從複製。

爲了更好的演示，搞了一臺雲服務器，Linux環境； 方便的同時，也能更符合實際應用場景；

正文

主從複製：主從指有多臺Redis服務器，其中一臺爲主服務器，其餘爲從服務器，能夠經過命令或配置實現主從關係；複製指將主服務器的數據同步到從服務器，數據只能從主服務器向從服務器單向同步；其做用以下：

• 讀寫分離：主服務器複製寫，各從服務器負責讀；根據二八原則，80%的操做都是讀，只有20%進行寫，因此在必定程度上也解決了單機瓶頸問題；
• 數據持久化更加安全：主從多臺服務器進行持久化操做，任意一臺服務宕機也不會影響數據恢復，避免了單點故障問題；
• 其餘：主從複製是實現哨兵模式和Redis集羣的前提，這個後續會說到。

好啦，老規矩，瞭解其做用以後，接下來就先實操再總結。

實現主從複製

每一臺Redis服務器啓動時，默認都是主服務器(Master)，能夠經過命令info replication查看，以下圖所示：

開始實操搭建一主二從的環境，以下：

1. 配置文件修改

因爲是在同一臺機器上模擬，因此將redis配置文件拷貝三份出來，主要修改項以下：

• 配置文件名稱：分別爲redis.conf、redis6388.conf、redis6399.conf；
• port：端口，三個配置文件分別修改成637九、638八、6399，這是爲了不同一臺機器演示端口衝突；
• pidfile：修改此文件名，避免文件衝突，改文件名便可，分別修改成redis.pid、redis6388.pid、redis6399.pid；
• dbfilename：持久化文件名，避免持久化文件衝突，分別修改成dump.rdb、dump6388.rdb、dump6399.rdb；

2. 啓動redis服務器

而後分別指定配置文件啓動redis-server，在redis中bin目錄下執行./redis-server redis.conf、./redis-server redis6388.conf、./redis-server redis6399.conf命令便可，能夠經過命令ps -ef | grep redis查看啓動redis效果，以下：

3.1 使用命令實現主從關係

默認狀況下，啓動的三臺服務器默認都是主服務器，如今能夠經過簡單的命令實現一主二從的關係，這裏以6379這臺服務器爲主，6388和6399兩臺服務器爲從，配置主從關係只針對從節點服務器配置便可，以下：

1. 分別連上6388和6399兩臺服務器，執行slaveof masterip masterport便可：

2. 從節點顯示沒問題，看看主節點狀態信息，連上6379這臺看看，以下：

3. 主從關係維護好了，接下來看看數據複製，一般主節點負責寫，將數據同步到從節點，從節點負責讀； 如今三臺服務器都沒數據，接下來往主節點中寫入點數據，看看是否能同步到從節點：

注：若是經過命令方式實現主從關係，那當從服務器重啓時，主從關係就丟了，還得手動再執行命令，因此推薦配置文件的形式進行配置；

3.2 經過配置文件實現主從配置

仍是很簡單的，主服務器不用動，僅修改從服務器配置文件，而後重啓便可，根據前面章節的學習經驗，打開配置文件，直接找到REPLICATION模塊進行以下配置修改：

• replicaof <masterip> <masterport> ：指定主節點ip和端口便可，如：replicaof 127.0.0.1 6379;
• masterauth <master-password>：指定主節點密碼，若是主節點配置密碼，直接經過這配置就行；

修改完這兩項，重啓服務器便可，和命令行同樣簡單，只是經過配置文件搭建的主從關係不會由於關閉服務器而丟失；這裏配置文件的演示就不截圖了，只是實現方式不同，其餘都是和命令行一致；

小總結

• 配從不配主，即只針對從服務器配置便可，主服務器無需配置；

• 一個主節點有多個從節點，從節點只能有一個主節點；從節點也能夠做爲其餘從節點的主節點，以下：

  這種方式的演示截圖就不提供了，小夥伴實操一把，這裏說明一下，雖然6388是6399的主節點，但扮演的角色仍是6379的從節點，只是它下面鏈接了其餘從節點而已；

• 若是用命令方式實現主從，主服務器斷開後，從新鏈接，主從關係還在；從服務器斷開以後重連關係消失，須要手動執行命令從新指定主節點；

• 若是但願斷開重連主從關係還在，推薦配置文件方式實現；

實現主從複製的搭建是否是很簡單，不論是命令仍是配置文件的方式，都很輕鬆實現；但小夥伴是否是也有疑問： 主從節點之間的數據是如何同步的？關於主從複製的其餘參數有什麼用？

主從複製原理

經過上面實操，在主服務器中寫入的數據，在無感知的狀況下就同步到各個從服務器，中間到底經歷了什麼呢？ 接下來簡單的瞭解一下；

在Redis2.8以前同步方式都以全量方式同步，以後爲了提升效率，數據複製方式分爲兩種，一種爲全量複製，一種爲部分複製：

• 全量複製：即將主服務器中的數據，所有同步到從服務器；通常是在從服務器啓動初始化數據的時候進行全量同步；
• 部分複製：即將未同步的增量數據，同步到從服務器，無需所有再同步一遍；通常用於因網絡中斷等沒法同步數據的狀況，待恢復正常以後，將中斷期間數據進行部分同步；

爲了方便查看日誌分析，使用兩臺redis服務器進行搭建主從， 將以前搭建的關係去除，經過修改配置文件重啓便可；

這裏以6388做爲主節點(Master)，6399做爲從節點(Slave)，當鏈接6399執行命令slaveof 127.0.0.1 6388配置主從關係時，主從節點分別打印日誌以下：

上圖是剛開始創建主從關係時，進行了全量複製，大概流程以下：

簡要說明：

1. 從節點與主節點創建鏈接，而後發送同步請求psync；
2. 主節點給從節點發送信息，replid和offset，這兩個參數後續是判斷是否部分複製的關鍵數據；
3. 主節點fork子進程將所有數據生成RDB文件；
4. 主節點期間接收到的寫命令存入到複製緩衝區中；
5. 當主節點RDB文件完成以後發送給從節點；
6. 從節點接收到文件，先清空老數據；
7. 從節點清空數據後，加載接收到的數據到內存中；
8. 主節點發送複製緩衝區中的數據到從節點；
9. 從節點接收到命令並執行，最終同步到最新數據；

主從關係是經過網絡進行通信，可能出現網絡中斷或網絡抖動狀況，致使短期的數據不能及時同步到從節點上，理想狀況下，當鏈接恢復的時候，但願只同步中斷期間的數據，從而提升同步效率，流程大概以下：

簡要說明：

1. 當主從之間因爲網絡中斷時，從節點會嘗試重連主節點；
2. 在此期間，主節點接收到的寫命令會記錄到複製緩衝區中；
3. 當網絡恢復，從節點連上主節點，會請求發佈同步請求psync，並帶上以前主節點發送過來的replid和offset；
4. 主節點接收到從節點的請求，會驗證接收的replid與主節點replid是否匹配，不匹配會進行全量複製；還會驗證offset數據偏移量是否在合法範圍內，若是中斷期間數據量過大，致使複製緩衝區的數據超出，主從節點的offset數據偏移量不一致，也會進行全複製；
5. 當從節點傳遞過來的replid和offset驗證經過時，則進行部分複製，並記錄最新的offset；

這裏就不模擬演示部分複製流程了，留給小夥伴操做。演示流程以下：已經搭建主從關係的兩臺機器，手動模擬網絡斷開，斷開期間在主服務器寫入數據，一會以後恢復網絡，查看主從服務器日誌打印狀況；

主從複製的相關配置參數

以上演示在配置文件中只是配置了部分參數，還有其餘參數的配置能夠輕鬆實現功能，這裏結合主從複製的內容能夠回顧一下相關配置參數的意義，以下：

• slaveof：設置本機爲從機，指定主機的IP和端口；
• masterauth：若是主機須要密碼，經過這設置；
• slave-serve-stale-data：從機若是與主機斷開或數據正在同步，獲取數據是否繼續，若是設置爲yes，還能夠正常讀取數據，設置爲no，獲取數據返回錯誤提示；
• slave-read-only：配置從主機爲只讀模式，默認爲yes，也強烈建議爲只讀模式；
• repl-diskless-sync：是否採用無磁盤方式進行主從傳遞數據，即採用Socket方式，默認沒采用，若是機器磁盤性能很差，而網絡環境良好，能夠嘗試使用這種模式；
• repl-diskless-sync-delay：當使用無磁盤方式傳遞數據時，服務器開始傳遞數據前等待指定時間，等待從服務器進入傳輸隊列，提升數據傳輸效率，默認爲5秒；
• repl-ping-slave-period：設置從機向主機發送ping消息間隔，即理解爲心跳檢測；
• repl-timeout：設置超時時間，主從機傳遞數據的時間，若是超過指定時間，從機會重連。通常主從複製數據比較大時，能夠將其改大，默認爲60s ；
• repl-disable-tcp-nodelay：主從複製數據是否採用TCP_NODELAY，默認爲no，表明不啓用，標識主機當即同步數據，保證數據一致性失效；若是設置爲yes，合併較小的TCP包一併發送，延遲高，但能夠提高帶寬性能，但推薦不啓用；
• repl-backlog-size：用於設置複製緩衝區的大小，此緩衝區用於從機斷開重連以後同步的增量數據，在必定時間內不用全量複製，提高同步效率；默認爲1mb，能夠根據需求進行修改；
• repl-backlog-ttl：設置從機斷開後沒有鏈接主機的間隔時間，超過此時間，設置的backlog緩衝區就會釋放，默認爲3600s；
• slave-priority：用於哨兵模式選擇，即當主機掛掉時，選擇優先級較高的從機代替掛掉的主機，快速恢復；默認值爲100；
• min-slaves-to-write 3：指可用從服務器少於3個時，主服務器只能讀，不能寫，通常和min-slaves-max-lag搭配用，默認不使用，根據須要進行配置；
• min-slaves-max-lag 10：指從服務器的延遲超過10秒時，主服務器也只能讀，不能寫，通常和min-slaves-to-write搭配用，默認不使用，根據須要進行配置；

主從複製有哪些問題

主從複製緩解了單節點性能和存儲的瓶頸，那又帶來什麼問題呢？

• 主從複製架構會有延時，儘快很快，也有，特別數據量和併發大的時候；目前的主從架構沒有好的方法處理延時，MySql、SqlServer也是如此；
• 過時Key數據在早期版本不能及時將從服務器數據失效，能夠升級到redis3.2以後解決，由於加入了過時判斷；
• 主節點宕機以後，只能手動從新配置主從關係，從服務器能夠執行slaveof no one命令重寫回到主服務器角色，而後從新配置主從關係；
• 若是從節點過多，當剛開始初始化數據全量同步或多個從節點斷開重連時，就會致使主節點的IO劇增；

總結

主從複製演練看似簡單，但還須要不斷在實踐中獲取經驗，搭配相關配置參數，從而使得更加適合應用場景；配置沒有固定都同樣，而是應用場景是否適合。隨着主節點宕機不能自動選舉的問題，下次在此基礎上說說哨兵模式，讓自動選舉不是問題；

一個被程序搞醜的帥小夥，關注"Code綜藝圈"，跟我一塊兒學~~~