談?wù)凴edis怎樣配置實現(xiàn)主從復制？

之前總結(jié)過redis的持久化機制：深度剖析Redis持久化機制，持久化機制主要解決redis數(shù)據(jù)單機備份問題；redis的高可用需要考慮數(shù)據(jù)的多機備份，多機備份通過主從復制來實現(xiàn)，這是redis高可用的基石。本文將詳細介紹redis主從復制的實現(xiàn)原理，在使用過程中應(yīng)該注意的問題和相關(guān)配置。

1. CAP理論

CAP理論是分布式領(lǐng)域的牛頓定律，所有的分布式存儲中間件都要使用它作為理論基石。如下圖所示：

這個原理很簡單，首先明確幾個概念：

C : Consistent, 一致性

A : Availability, 可用性

P : Partition tolerance, 分區(qū)容忍性

分布式系統(tǒng)的節(jié)點往往分布在不同的機器上，它們之間由網(wǎng)絡(luò)進行隔離，當網(wǎng)絡(luò)斷開時就會產(chǎn)生網(wǎng)絡(luò)分區(qū)。網(wǎng)絡(luò)分區(qū)不可避免，但是當網(wǎng)絡(luò)分區(qū)發(fā)生時，對分布式系統(tǒng)中一個節(jié)點的修改操作無法同步給其它節(jié)點，數(shù)據(jù)一致性也就無法滿足；想要滿足一致性，除非犧牲可用性，也就是暫停分布式節(jié)點服務(wù)，等到網(wǎng)絡(luò)恢復，數(shù)據(jù)一致后，再對外提供服務(wù)。分布式系統(tǒng)中網(wǎng)絡(luò)分區(qū)不可避免，一致性和可用性水火不容。這就是cap理論:網(wǎng)絡(luò)分區(qū)發(fā)生時，一致性和可用性兩難全 。

基于 Spring Boot + MyBatis Plus + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項目地址：https://github.com/YunaiV/ruoyi-vue-pro

視頻教程：https://doc.iocoder.cn/video/

2. redis主從復制

2.1 概述

互聯(lián)網(wǎng)圈經(jīng)常談“三高”架構(gòu)：高并發(fā)、高性能、高可用 。對于redis來說，高并發(fā)、高性能可以保證，高可用需要架構(gòu)的設(shè)計，單機redis由于存在系統(tǒng)崩潰、硬盤故障的風險，還有內(nèi)存的限制，所以企業(yè)一般都會搭建主從，對系統(tǒng)有更高要求會搭建集群。

為了保持數(shù)據(jù)一致性，主節(jié)點(master)只寫，從節(jié)點(slave)只讀，數(shù)據(jù)由主節(jié)點復制給從節(jié)點，這個復制的過程就是主從復制 。

redis的主從復制是異步的，分布式的redis系統(tǒng)并不滿足一致性要求，但是在網(wǎng)絡(luò)斷開的情況下，主節(jié)點依然可以對外提供服務(wù)，滿足可用性。redis保證最終一致性，從節(jié)點會努力追趕主節(jié)點，最終從節(jié)點的狀態(tài)會和從節(jié)點保持一致。網(wǎng)絡(luò)斷開的情況下，主從節(jié)點數(shù)據(jù)會出現(xiàn)大量的不一致，但一旦網(wǎng)絡(luò)恢復，從節(jié)點會繼續(xù)追趕主節(jié)點，最終達到和主節(jié)點狀態(tài)一致。

為了減輕redis主節(jié)點的同步負擔，redis 的后續(xù)版本還增加了從從同步，與此同時，數(shù)據(jù)一致性會變差。

2.2 主從復制的作用

主從復制在服務(wù)中起到了什么效果呢？

讀寫分離：master寫，slave讀，提高服務(wù)器的讀寫負載能力。

負載均衡：基于主從架構(gòu)，配合讀寫分離，由slave分擔master負載，并根據(jù)需求的變化，改變slave的數(shù)量，通過多個從節(jié)點分擔數(shù)據(jù)讀取負載，大大提高redis服務(wù)器并發(fā)量和數(shù)據(jù)吞吐量。

故障恢復：當master出現(xiàn)問題時，由slave提供服務(wù)，實現(xiàn)快速的故障恢復。

數(shù)據(jù)冗余：實現(xiàn)數(shù)據(jù)熱備份，是持久化之外的一種數(shù)據(jù)冗余方式。

高可用基石：基于主從復制，構(gòu)建哨兵模式與集群，實現(xiàn)redis的高可用方案。

2.3 怎樣配置實現(xiàn)主從復制？

有三種配置實現(xiàn)redis的主從：

方式一：客戶端發(fā)送命令

slaveof??

方式二：啟動服務(wù)器時添加參數(shù)

redis-server?-slaveof??

方式三：服務(wù)器配置文件中配置(通過redis.conf)

slaveof??

比較主流的用法是通過配置文件的方式實現(xiàn)主從。還有其它的一些命令：

主從斷開連接，可以從客戶端發(fā)送命令

slaveof?no?one

服務(wù)端設(shè)置了授權(quán)訪問

#master有兩種方式設(shè)置

//--?1.master配置文件中設(shè)置
requirepass?
//--?2.master客戶端發(fā)送命令設(shè)置密碼
config?set?requirepass?
config?get?requirepass

#slave有三種方式實現(xiàn)認證
//--?1.客戶端發(fā)送命令設(shè)置密碼
auth?
//--?2.slave配置文件設(shè)置密碼
masterauth?
//--?3.啟動客戶端設(shè)置密碼
redis-cli?-a?

2.4 redis主從復制的工作流程

redis主從復制實現(xiàn)過程有三個階段:

建立連接、數(shù)據(jù)同步、命令傳播。建立連接階段主從節(jié)點建立通信的橋梁，彼此之間同步一些基礎(chǔ)信息；數(shù)據(jù)同步階段實現(xiàn)從節(jié)點全量同步主節(jié)點的數(shù)據(jù)；從節(jié)點同步完主節(jié)點數(shù)據(jù)之后，就進入了命令傳播階段，主節(jié)點接收寫請求，數(shù)據(jù)不斷發(fā)生變化，通過命令傳播階段主節(jié)點將數(shù)據(jù)源源不斷的同步給從節(jié)點。下邊我們詳細介紹主從復制這三個階段的工作細節(jié)和注意事項。

2.4.1 建立連接階段

建立slave到master的連接，使master能識別slave, 并保存slave的端口號；與此同時，slave也保存master的地址和端口號信息。

slave發(fā)送slaveof ip port命令給master,master響應(yīng)slave

slave保存master的ip和端口號，建立socket連接

在socket連接之上，主從節(jié)點實現(xiàn)了心跳機制，這部分內(nèi)容也比較重要，后邊會提到。

如果有認證機制，從節(jié)點通過上邊說到的認證指令，發(fā)送認證信息給master,實現(xiàn)認證。

從節(jié)點將自己的端口信息發(fā)送發(fā)送給主節(jié)點，主節(jié)點保存。

通過以上過程主從之間的連接就建立了。

2.4.2 數(shù)據(jù)同步階段

數(shù)據(jù)同步階段實現(xiàn)的功能是從節(jié)點從主節(jié)點同步全量的數(shù)據(jù)。這個過程又分為幾個小階段，最主要的就是數(shù)據(jù)的全量復制和部分復制, 對應(yīng)的流程就是主節(jié)點發(fā)送rdb文件同步數(shù)據(jù)和發(fā)送緩沖區(qū)寫命令(aof)同步數(shù)據(jù)給從節(jié)點。下圖是實現(xiàn)細節(jié)：

首先slave節(jié)點先發(fā)起命令psync ? -1,向master節(jié)點要全量數(shù)據(jù)。

master節(jié)點接收到指令以后，執(zhí)行bgsave，將當前內(nèi)存數(shù)據(jù)快照保存為rdb文件，這個過程為了不影響主節(jié)點繼續(xù)對外提供服務(wù)，采用了Copy On Write技術(shù)。與此同時，master節(jié)點也會將bgsave保存快照期間接收到的寫更新命令添加到復制擠壓緩沖區(qū)當中。master節(jié)點rdb文件生成完畢以后，會通過第一階段建立的socket連接將它發(fā)送給slave節(jié)點，還會發(fā)送+FULLRESYNC runid offset給slave節(jié)點，告訴slave節(jié)點自己的runid和offset。

什么是runid?

redis-server在每次啟動的時候都會生成一個runid,因為redis-server是一個守護進程，所以在運行期間，runid不會發(fā)生變化，可以通過info server指令查看runid，它是一個40位字符長度的字符串。上文提到的psync有兩個參數(shù)，和+FULLRESYNC一樣：psync ；runid的意義是什么呢？當master節(jié)點發(fā)生故障發(fā)生了變更后，在接到slave的指令以后，對比參數(shù)中的runid如果和自己的runid不一致，就會再次進行全量復制，因為換主了。

什么是復制擠壓緩沖區(qū)和offset?

復制擠壓緩沖區(qū)是一個先進先出(FIFO)的環(huán)形隊列，用于存儲服務(wù)端執(zhí)行過的命令，每次傳播命令，master節(jié)點都會將傳播的命令記錄下來，保存在這里。

復制擠壓緩沖區(qū)由兩部分組成：偏移量和字節(jié)值。字節(jié)值是redis指令字節(jié)的存儲（redis指令以一種Redis序列化文本協(xié)議的格式存儲），偏移量offset就是當前字節(jié)值在環(huán)形隊列中的偏移量。

slave節(jié)點接收完master節(jié)點同步的rdb文件之后，將rdb的內(nèi)容加載到自己的內(nèi)存，然后將master節(jié)點的runid和offset記錄下來。

有了master節(jié)點的runid和offset，在加載完rdb文件之后，就開始向master節(jié)點發(fā)送新的命令psync runid offset，向master節(jié)點要新數(shù)據(jù)。新數(shù)據(jù)是master節(jié)點在bgsave生成rdb文件時和向slave同步數(shù)據(jù)的這段時間產(chǎn)生的，所以這段時間的工作也稱為部分復制。

master節(jié)點收到slave節(jié)點發(fā)送的請求數(shù)據(jù)命令之后，會檢查runid是否一致（是否換主），offset是否一致(因為復制擠壓緩沖區(qū)是定長的，所有有可能會溢出)，這兩個條件只要有一個不滿足，master就會向slave再次全量的同步數(shù)據(jù)(讀者可能會發(fā)現(xiàn)，如果master節(jié)點寫并發(fā)很高，復制擠壓緩沖區(qū)又設(shè)置的比較小的話，可能會每次向slave同步完數(shù)據(jù)以后，每次復制擠壓緩沖區(qū)都會溢出，造成主從之間循環(huán)的全量復制。這確實是應(yīng)該規(guī)避的問題！我們后邊會針對主從復制應(yīng)該考慮的問題做一個總結(jié))。在runid和offset都滿足的情況下，master節(jié)點就會向slave節(jié)點發(fā)送指令+CONTINUE offset，接著從offset位置開始同步數(shù)據(jù)，數(shù)據(jù)都在主節(jié)點的復制擠壓緩沖區(qū)中了，所以直接復制發(fā)送就可以了。

slave節(jié)點接收到master節(jié)點發(fā)送的+CONTINUE offset指令之后，更新自己保存的offset值，然后將從master節(jié)點同步過來的數(shù)據(jù)，使用bgrewriteaof，重放aof數(shù)據(jù)。

到這里，主從復制的第二階段：數(shù)據(jù)同步階段工作就完成了。

2.4.3 命令傳播階段

命令傳播階段類似于數(shù)據(jù)同步階段的部分復制，當master節(jié)點數(shù)據(jù)被修改以后，就和slave節(jié)點的數(shù)據(jù)不一致了，這個時候master節(jié)點就會根據(jù)slave上報的offset開始傳播數(shù)據(jù)（一主多從的架構(gòu)中，master節(jié)點要記錄每一個slave的offset）。slave接收到數(shù)據(jù)以后，執(zhí)行bgrewriteaof重放數(shù)據(jù)。在這個工作過程中，如果因為網(wǎng)路問題導致offset溢出或者換主的情況，主從之間還是會進行數(shù)據(jù)的全量同步的。

2.5 心跳機制

進入命令傳播階段以后，master節(jié)點與slave節(jié)點需要進行信息傳遞，使用心跳機制進行維護，實現(xiàn)雙方保持在線。

master節(jié)點心跳使用指令PING,由配置repl-ping-slave-period決定，默認10秒,作用是判斷slave是否在線，可以通過info replication獲取slave最后一次連接到現(xiàn)在的時間間隔，lag的值維護在0和1視為正常。

slave節(jié)點的心跳任務(wù)使用指令REPLCONF ACK {offset}，周期是1秒，slave的心跳任務(wù)有兩個作用：

匯報自己的offset給master,這在數(shù)據(jù)傳播起到了關(guān)鍵性作用，因為master節(jié)點向slave節(jié)點傳播數(shù)據(jù)，offset是一項非常重要的指標。

判斷master是否在線

在心跳階段應(yīng)該注意：當slave節(jié)點多數(shù)掉線，或者延遲過高時，master節(jié)點為了保證數(shù)據(jù)的穩(wěn)定性，將拒絕所有信息的同步。有如下配置：

min-slaves-to-write?2
min-slaves-max-lag?8

上述配置含義是：當slave數(shù)量小于2個，或者所有的slave的延遲都大于等于8秒時，強制關(guān)閉master寫功能，停止數(shù)據(jù)同步。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項目地址：https://github.com/YunaiV/yudao-cloud

視頻教程：https://doc.iocoder.cn/video/

3.主從復制常見問題

上邊介紹的主從復制是建立在主從節(jié)點間的網(wǎng)絡(luò)和服務(wù)都正常的情況下，業(yè)務(wù)場景中要考慮更多的實際情況。

3.1 master重啟

伴隨著系統(tǒng)的運行，master節(jié)點的內(nèi)存數(shù)據(jù)量變得很大的情況下，一旦master節(jié)點重啟，runid將發(fā)生變化，會導致slave的全量復制操作。

這里有一個優(yōu)化方案：在master節(jié)點內(nèi)部創(chuàng)建master_replid變量，使用runid相同的策略生成，長度41位，發(fā)送給所有的slave節(jié)點。在master節(jié)點關(guān)閉時，執(zhí)行命令shutdown save，進行RDB的數(shù)據(jù)持久化，將runid與offset保存在RDB文件中。在RDB文件中有了repl-id和repl-offset信息以后，通過指令redis-check-rdb命令可以查看這些信息。在master節(jié)點重啟后，將RDB文件加載到內(nèi)存中以后，也會將repl-id和repl-offset加載到內(nèi)存中。通過info 指令可以查看：

master_repl_id?=?repl

master_repl_offset?=?repl-offset

作用是：master節(jié)點重啟之后會保存原來的runid,重啟后恢復該值，會讓所有的slave節(jié)點認為還是之前的master節(jié)點。

3.2 復制積壓緩沖區(qū)太小

當復制積壓緩沖區(qū)太小的時候，當master節(jié)點寫并發(fā)很大，master節(jié)點和slave節(jié)點網(wǎng)絡(luò)有抖動的時候，就會導致數(shù)據(jù)同步不及時，造成offset溢出，進而導致全量復制。這個時候，我們可以考慮修改復制積壓緩沖區(qū)的大小，由配置repl-backlog-size控制。設(shè)置多大比較合適呢，這要根據(jù)master的并發(fā)量和網(wǎng)絡(luò)情況做具體的評估。

3.3 slave執(zhí)行了keys * 、hgetall等命令

前邊內(nèi)容我們提到slave節(jié)點每秒都會發(fā)送REPLCONF ACK指令到master節(jié)點，master節(jié)點調(diào)用復制函數(shù)relicationCron()同步數(shù)據(jù)給slave節(jié)點時，如果slave節(jié)點執(zhí)行了keys *、hgetall等阻塞命令的時候，就會在很長一段時候得不到響應(yīng)。這就會導致master的各種資源(輸出緩沖區(qū)、帶寬、連接)等被占用。master節(jié)點的CPU就會變高，slave頻繁的斷開連接。

解決方案是master節(jié)點通過配置：repl-timeout設(shè)置合理的超時時間(默認60s)，超過改值，master節(jié)點將釋放slave節(jié)點。

3.4 master節(jié)點發(fā)送ping指令頻度低，網(wǎng)絡(luò)存在丟包

master節(jié)點默認10s向slave節(jié)點發(fā)送一次ping指令，因為master節(jié)點不僅要處理大量的寫任務(wù)，還可能維護著多個master，所以ping設(shè)置的不太及時。但是當ping指令在網(wǎng)絡(luò)中存在丟包時，master節(jié)點如果設(shè)置的超時時間太短，就會導致master節(jié)點與slave節(jié)點斷開連接。

解決方案有：提高master節(jié)點ping的頻度，超時時間repl-time設(shè)置為ping指令時間的5～10倍。

3.5 網(wǎng)絡(luò)信息不同步，數(shù)據(jù)發(fā)送有延遲

當主從同步中網(wǎng)絡(luò)數(shù)據(jù)發(fā)送有延遲的時候，就會造成多個slave獲取到的數(shù)據(jù)不同步，解決方案是優(yōu)化master節(jié)點和slave節(jié)點的網(wǎng)絡(luò)環(huán)境，通常是放置在一個機房部署。另外要監(jiān)控master和slave節(jié)點的延遲，如果延遲過大，可以暫時屏蔽對slave節(jié)點的訪問。通過下面指令設(shè)置：

slave-serve-stale-data?yes?|?no

開啟后，slave節(jié)點僅僅能響應(yīng)info、slaveof等少數(shù)命令，除非對數(shù)據(jù)一致性要求很高，否則不要輕易這樣使用。

4.總結(jié)

本文主要總結(jié)了redis實現(xiàn)主從復制的實現(xiàn)細節(jié)和注意事項。redis的主從復制是實現(xiàn)高可用的重要基石，后邊的文章將總結(jié)哨兵和集群的搭建。

編輯：黃飛

?