Redis主從復(fù)制原理是什么

一、什么是Redis主從復(fù)制？

主從復(fù)制就是現(xiàn)在有倆臺redis服務(wù)器，把一臺redis的數(shù)據(jù)同步到另一臺redis數(shù)據(jù)庫上。前者稱之為主節(jié)點（master），后者為從節(jié)點（slave）。數(shù)據(jù)是只能master往slave同步單向。

但是在實際過程中是不可能只有倆臺redis服務(wù)器來做主從復(fù)制的，這也就意味這每臺redis服務(wù)器都有可能會稱為主節(jié)點（master）

下圖案例中，我們的slave3既是master的從節(jié)點，也是slave的主節(jié)點。

先知道這么個概念，更多詳解繼續(xù)查看下文。

二、為什么需要Redis主從復(fù)制？

假設(shè)我們現(xiàn)在就一臺redis服務(wù)器，也就是單機(jī)狀態(tài)。

在這種情況下會出現(xiàn)的第一個問題就是服務(wù)器宕機(jī)，直接導(dǎo)致數(shù)據(jù)丟失。如果項目是跟￥占關(guān)系的，那造成的后果就可想而知。

第二個情況就是內(nèi)存問題了，當(dāng)只有一臺服務(wù)器時內(nèi)存肯定會到達(dá)峰值的，不可能對一臺服務(wù)器進(jìn)行無限升級的。所以針對以上倆個問題，我們就多準(zhǔn)備幾臺服務(wù)器，配置主從復(fù)制。將數(shù)據(jù)保存在多個服務(wù)器上。并且保證每個服務(wù)器的數(shù)據(jù)是同步的。即使有一個服務(wù)器宕機(jī)了，也不會影響用戶的使用。redis可以繼續(xù)實現(xiàn)高可用、同時實現(xiàn)數(shù)據(jù)的冗余備份。

這會應(yīng)該會有很多疑問，master跟slave怎么連接呢？  如何同步數(shù)據(jù)呢？  假如master服務(wù)器宕機(jī)了呢？別著急，一點一點解決你的問題。

三、Redis主從復(fù)制的作用

在上邊我們說了為什么使用redis的主從復(fù)制，那么主從復(fù)制的作用就是針對為什么使用它來講了。

1. 我們繼續(xù)使用這個圖來談?wù)?/section>
2. 第一點是數(shù)據(jù)冗余了，實現(xiàn)了數(shù)據(jù)的熱備份，是持久化之外的另一種方式。
3. 第二點是針對單機(jī)故障問題。當(dāng)主節(jié)點也就是master出現(xiàn)問題時，可以由從節(jié)點來提供服務(wù)也就是slave，實現(xiàn)了快速恢復(fù)故障，也就是服務(wù)冗余。
4. 第三點是讀寫分離，master服務(wù)器主要是寫，slave主要用來讀數(shù)據(jù)，可以提高服務(wù)器的負(fù)載能力。同時可以根據(jù)需求的變化，添加從節(jié)點的數(shù)量。
5. 第四點是負(fù)載均衡，配合讀寫分離，有主節(jié)點提供寫服務(wù)，從節(jié)點提供讀服務(wù)，分擔(dān)服務(wù)器負(fù)載，尤其在寫少讀多的情況下，通過多個從節(jié)點分擔(dān)讀負(fù)載，可以大大提高redis服務(wù)器的并發(fā)量和負(fù)載。
6. 第五點是高可用的基石，主從復(fù)制是哨兵和集群能夠?qū)嵤┑幕A(chǔ)，因此我們可以說主從復(fù)制是高可用的基石。

四、配置Redis主從復(fù)制

說了這么多，我們先簡單的配置一個主從復(fù)制案例，然后在談實現(xiàn)的原理。

redis存儲路徑為：usr/local/redis

日志跟配置文件存儲在：usr/local/redis/data

首先我們先配置倆個配置文件，分別為redis6379.conf  和  redis6380.conf修改配置文件，主要就是修改端口。為了查看方便在把日志文件和持久化文件的名字都用各自的端口來做標(biāo)識。然后分別開啟倆個redis服務(wù)，一個端口為6379，一個端口為6380。執(zhí)行命令redis-server redis6380.conf,然后使用redis-cli -p 6380連接，因為redis的默認(rèn)端口就是6379所以我們啟動另外一臺redis服務(wù)器直接使用redis-server redis6379.conf 然后直接使用redis-cli直接連接就可以。這個時候我們就成功的配置了倆個redis服務(wù)，一臺為6380，一臺為6379，這里只是為了演示。實際工作中是需要配置在倆臺不同的服務(wù)器的。

1. 使用客戶端命令行啟動

我們先得有一個概念，就是在配置主從復(fù)制時，所有的操作都是在從節(jié)點來操作，也就是slave。

那么我們在從節(jié)點執(zhí)行一個命令為 slaveof 127.0.0.1 6379，執(zhí)行完就代表我們連接上了。我們先測試一下看是否實現(xiàn)主從復(fù)制。在master這臺服務(wù)器上執(zhí)行倆個set kaka 123 和 set master 127.0.0.1，然后在slave6380端口是可以成功獲取到的，也就說明我們的主從復(fù)制就已經(jīng)配置完成了。但是在實現(xiàn)生產(chǎn)環(huán)境可不是就這樣完事了，后邊會在進(jìn)一步對主從復(fù)制進(jìn)行優(yōu)化，直到實現(xiàn)高可用。

2. 使用配置文件啟用

在使用配置文件啟動主從復(fù)制之前呢！先需要把之前使用客戶端命令行連接的斷開，在從主機(jī)執(zhí)行slaveof no one即可斷開主從復(fù)制。在哪可以查看從節(jié)點已經(jīng)斷開了主節(jié)點呢！在主節(jié)點的客戶端輸入命令行info查看

這張圖是使用從節(jié)點使用客戶端命令行連接主節(jié)點后，在主節(jié)點的客戶端輸入info打印的信息，可以看到有一個slave0的一個信息。這個圖是在從節(jié)點執(zhí)行完slaveof no one  后，在主節(jié)點打印的info，說明從節(jié)點已經(jīng)跟主節(jié)點斷開連接了。在根據(jù)配置文件啟動redis服務(wù)，redis-server redis6380.conf

當(dāng)在從節(jié)點重新啟動后就可以在主節(jié)點直接查看到從節(jié)點的連接信息。測試數(shù)據(jù)，主節(jié)點寫的東西，從節(jié)點還是會自動同步的。

3. 啟動redis服務(wù)器時啟動

這種方式配置也是很簡單，在啟動redis服務(wù)器時直接就啟動主從復(fù)制，執(zhí)行命令：redis-server --slaveof host port  即可。

4. 主從復(fù)制啟動后的日志信息查看

這個是主節(jié)點的日志信息這個是從節(jié)點的信息，其中有連接主節(jié)點信息，還有RDB快照保存。

五、主從復(fù)制工作原理

1. 主從復(fù)制的三個階段

主從復(fù)制完整的工作流程分為以下三個階段。每一段都有自己的內(nèi)部工作流程，那么我們會對這三個過程進(jìn)行談?wù)摗?/p>

• 建立連接過程：這個過程就是slave跟master連接的過程
• 數(shù)據(jù)同步過程：是master給slave同步數(shù)據(jù)的過程
• 命令傳播過程：是反復(fù)同步數(shù)據(jù)

2. 第一階段：建立連接過程

上圖是一個完整主從復(fù)制建立連接工作流程。然后使用簡短的話語來描述上邊的工作流程。

1. 設(shè)置master的地址和端口，保存master的信息
2. 建立socket連接（這個連接做的事情下文會說）
3. 持續(xù)發(fā)送ping命令
4. 身份驗證
5. 發(fā)送slave端口信息

在建立連接的過程中，從節(jié)點會保存master的地址和端口、主節(jié)點master保存從節(jié)點slave的端口。

3. 第二階段：數(shù)據(jù)同步階段過程

這張圖是詳細(xì)描述第一次從節(jié)點連接主節(jié)點時的數(shù)據(jù)同步過程。

當(dāng)從節(jié)點第一次連接主節(jié)點時，先會執(zhí)行一次全量復(fù)制這次的全量復(fù)制是無法避免的。

全量復(fù)制執(zhí)行完成后，主節(jié)點就會發(fā)送復(fù)制積壓緩沖區(qū)的數(shù)據(jù)，然后從節(jié)點就會執(zhí)行bgrewriteaof恢復(fù)數(shù)據(jù)，這也就是部分復(fù)制。

在這個階段提到了三個新點，全量復(fù)制、部分復(fù)制、復(fù)制緩沖積壓區(qū)。會在下文的常見問題里詳細(xì)說明這幾個點。

4. 第三階段：命令傳播階段

當(dāng)master數(shù)據(jù)庫被修改后，主從服務(wù)器的數(shù)據(jù)不一致后，此時就會讓主從數(shù)據(jù)同步到一致，這個過程稱之為命令傳播。

master會將接收到的數(shù)據(jù)變更命令發(fā)送給slave，slave接收命令后執(zhí)行命令，讓主從數(shù)據(jù)達(dá)到一致。

「命令傳播階段的部分復(fù)制」

• 在命令傳播階段出現(xiàn)斷網(wǎng)的情況，或者網(wǎng)絡(luò)抖動時會導(dǎo)致連接斷開（connection  lost）

• 這個時候主節(jié)點master還是會繼續(xù)往replbackbuffer（復(fù)制緩沖積壓區(qū)）寫數(shù)據(jù)

• 從節(jié)點會繼續(xù)嘗試連接主機(jī)（connect to master）

• 當(dāng)從節(jié)點把自己的runid和復(fù)制偏移量發(fā)送給主節(jié)點，并且執(zhí)行pysnc命令同步

• 如果master判斷偏移量是在復(fù)制緩沖區(qū)范圍內(nèi)，就會返回continue命令。并且發(fā)送復(fù)制緩沖區(qū)的數(shù)據(jù)給從節(jié)點。

• 從節(jié)點接收數(shù)據(jù)執(zhí)行bgrewriteaof，恢復(fù)數(shù)據(jù)

六. 詳細(xì)介紹主從復(fù)制原理（全量復(fù)制+部分復(fù)制）

這個過程就是主從復(fù)制最齊全的流程講解。那么下來我們對每一步進(jìn)程簡單的介紹

1. 從節(jié)點發(fā)送指令psync ? 1 psync runid offset   找對應(yīng)的runid索取數(shù)據(jù)。但是這里可以考慮一下，當(dāng)從節(jié)點第一次連接的時候根本就不知道主節(jié)點的runid 和 offset  。所以第一次發(fā)送的指令是psync ？ 1意思就是主節(jié)點的數(shù)據(jù)我全要。
2. 主節(jié)點開始執(zhí)行bgsave生成RDB文件，記錄當(dāng)前的復(fù)制偏移量offset
3. 主節(jié)點這個時候會把自己的runid  和  offset  通過 +FULLRESYNC  runid  offset   指令  通過socket發(fā)送RDB文件給從節(jié)點。
4. 從節(jié)點接收到+FULLRESYNC  保存主節(jié)點的runid和offset    然后清空當(dāng)前所有數(shù)據(jù)，通過socket接收RDB文件，開始恢復(fù)RDB數(shù)據(jù)。
5. 在全量復(fù)制后，從節(jié)點已經(jīng)獲取到了主節(jié)點的runid和offset，開始發(fā)送指令 psync runid offset
6. 主節(jié)點接收指令，判斷runid是否匹配，判斷offset是否在復(fù)制緩沖區(qū)中。
7. 主節(jié)點判斷runid和offset有一個不滿足，就會在返回到步驟2繼續(xù)執(zhí)行全量復(fù)制。這里的runid不匹配只有的可能是從節(jié)點重啟了這個問題后邊會解決，offset（偏移量）不匹配就是復(fù)制積壓緩沖區(qū)溢出了。 如果runid或offset校驗通過，從節(jié)點的offset和主節(jié)點的offset相同時則忽略。 如果runid或offset檢驗通過，從節(jié)點的offset與offset不相同，則會發(fā)送 +CONTINUE  offset(這個offset為主節(jié)點的)，通過socket發(fā)送復(fù)制緩沖區(qū)中從節(jié)點offset到主節(jié)點offset的數(shù)據(jù)。
8. 從節(jié)點收到+CONTINUE 保存master的offset  通過socket接收到信息后，執(zhí)行bgrewriteaof，恢復(fù)數(shù)據(jù)。

「1-4是全量復(fù)制    5-8是部分復(fù)制」

在主節(jié)點的第3步下面  主節(jié)點在主從復(fù)制的期間是一直在接收客戶端的數(shù)據(jù)，主節(jié)點的offset是一直變化的。只有有變化就會給每個slave進(jìn)行發(fā)送，這個發(fā)送的過程稱之為心跳機(jī)制

七. 心跳機(jī)制

在命令傳播階段是，主節(jié)點與從節(jié)點之間一直都需要進(jìn)行信息互換，使用心跳機(jī)制進(jìn)行維護(hù)，實現(xiàn)主節(jié)點和從節(jié)點連接保持在線。

• master心跳

  • 指令：ping
  • 默認(rèn)10秒進(jìn)行一次，是由參數(shù)repl-ping-slave-period決定的
  • 主要做的事情就是判斷從節(jié)點是否在線
  • 可以使用info replication  來查看從節(jié)點租后一次連接時間的間隔，lag為0或者為1就是正常狀態(tài)。

• slave心跳任務(wù)

  • 指令：replconf ack {offset}
  • 每秒執(zhí)行一次
  • 主要做的事情是給主節(jié)點發(fā)送自己的復(fù)制偏移量，從主節(jié)點獲取到最新的數(shù)據(jù)變更命令，還做一件事情就是判斷主節(jié)點是否在線。

「心跳階段的注意事項」主節(jié)點為保障數(shù)據(jù)穩(wěn)定性，當(dāng)從節(jié)點掛掉的數(shù)量或者延遲過高時。將會拒絕所有信息同步。

這里有倆個參數(shù)可以進(jìn)行配置調(diào)整：

min-slaves-to-write   2

min-slaves-max-lag 8

這倆個參數(shù)表示從節(jié)點的數(shù)量就剩余2個，或者從節(jié)點的延遲大于8秒時，主節(jié)點就會強(qiáng)制關(guān)閉maste功能，停止數(shù)據(jù)同步。

那么主節(jié)點是如何知道從節(jié)點掛掉的數(shù)量和延遲時間呢！  在心跳機(jī)制里邊slave 會每隔一秒發(fā)送perlconf  ack  這個指令，這個指令可攜帶偏移量，也可以攜帶從節(jié)點的延遲時間和從節(jié)點的數(shù)量。

八、部分復(fù)制的三個核心要素

1. 服務(wù)器的運行id （run id）

我們先看一下這個run id是什么，執(zhí)行info命令即可看到。在上文中我們查看啟動日志信息也可以看到。

redis在啟動時會自動生成一個隨機(jī)的id（這里需要注意的是每次啟動的id都會不一樣），是由40個隨機(jī)的十六進(jìn)制字符串組成，用來唯一識別一個redis節(jié)點。

在主從復(fù)制初次啟動時，master會把自己的runid發(fā)送給slave，slave會保存master的這個id，我們可以使用info命令查看

當(dāng)斷線重連時，slave把這個id發(fā)送給master，如果slave保存的runid與master現(xiàn)在的runid相同，master會嘗試使用部分復(fù)制（這塊能否復(fù)制成功還有一個因素就是偏移量）。如果slave保存的runid與master現(xiàn)在的runid不同，則會直接進(jìn)行全量復(fù)制。

2. 復(fù)制積壓緩沖區(qū)

復(fù)制緩沖積壓區(qū)是一個先進(jìn)先出的隊列，用戶存儲master收集數(shù)據(jù)的命令記錄。復(fù)制緩沖區(qū)的默認(rèn)存儲空間是1M。

可以在配置文件修改repl-backlog-size 1mb來控制緩沖區(qū)大小，這個比例可以根據(jù)自己的服務(wù)器內(nèi)存來修改，咔咔這邊是預(yù)留出了30%左右。

「復(fù)制緩沖區(qū)到底存儲的是什么？」

當(dāng)執(zhí)行一個命令為set name kaka時，我們可以查看持久化文件查看那么復(fù)制積壓緩沖區(qū)就是存儲的aof持久化的數(shù)據(jù)，并且以字節(jié)分開，并且每個字節(jié)都有自己的偏移量。這個偏移量也就是復(fù)制偏移量（offset）「那為什么會說復(fù)制緩沖積壓區(qū)有可能會導(dǎo)致全量復(fù)制呢」

在命令傳播階段，主節(jié)點會把收集的數(shù)據(jù)存儲到復(fù)制緩沖區(qū)中，然后在發(fā)送給從節(jié)點。就是這里出現(xiàn)了問題，當(dāng)主節(jié)點數(shù)據(jù)量在一瞬間特別大的時候，超出了復(fù)制緩沖區(qū)的內(nèi)存，就會有一部分?jǐn)?shù)據(jù)會被擠出去，從而導(dǎo)致主節(jié)點和從節(jié)點的數(shù)據(jù)不一致。從而進(jìn)行全量復(fù)制。如果這個緩沖區(qū)大小設(shè)置不合理那么很大可能會造成死循環(huán)，從節(jié)點就會一直全量復(fù)制，清空數(shù)據(jù)，全量復(fù)制。

3. 復(fù)制偏移量（offset）

主節(jié)點復(fù)制偏移量是給從節(jié)點發(fā)送一次記錄一次，從節(jié)點是接收一次記錄一次。

用于同步信息，對比主節(jié)點和從節(jié)點的差異，當(dāng)slave斷聯(lián)時恢復(fù)數(shù)據(jù)使用。

這個值也就是來自己于復(fù)制緩沖積壓區(qū)里邊的那個偏移量。

九. 主從復(fù)制常見的問題

1. 主節(jié)點重啟問題（內(nèi)部優(yōu)化）

當(dāng)主節(jié)點重啟后，runid的值將發(fā)生變化，會導(dǎo)致所有的從節(jié)點進(jìn)行全量復(fù)制。

這個問題我們無需考慮，知道系統(tǒng)是怎么優(yōu)化的即可。

在建立完主從復(fù)制后主節(jié)點會創(chuàng)建master-replid變量，這個生成的策略跟runid一樣，長度是41位，runid長度是40位，然后發(fā)送給從節(jié)點。

在主節(jié)點執(zhí)行shutdown  save命令時，進(jìn)行了一次RDB持久化會把runid 和 offset保存到RDB文件中?？梢允褂妹顁edis-check-rdb查看該信息。

主節(jié)點重啟后加載RDB文件，將文件中的repl-id  和repl-offset加載到內(nèi)存中?？v使讓所有從節(jié)點認(rèn)為還是之前的主節(jié)點。

2. 從節(jié)點網(wǎng)絡(luò)中斷偏移量越界導(dǎo)致全量復(fù)制

由于網(wǎng)絡(luò)環(huán)境不佳，從節(jié)點網(wǎng)絡(luò)中斷。復(fù)制積壓緩沖區(qū)內(nèi)存過小導(dǎo)致數(shù)據(jù)溢出，伴隨著從節(jié)點偏移量越界，導(dǎo)致全量復(fù)制。有可能會導(dǎo)致反復(fù)的全量復(fù)制。

解決方案：修改復(fù)制積壓緩沖區(qū)的大小：repl-backlog-size

設(shè)置建議：測試主節(jié)點連接從節(jié)點的時間，獲取主節(jié)點每秒平均產(chǎn)生的命令總量write_size_per_second

復(fù)制緩沖區(qū)空間設(shè)置  =   2  *  主從連接時間   *   主節(jié)點每秒產(chǎn)生的數(shù)據(jù)總量

3. 頻繁的網(wǎng)路中斷

由于主節(jié)點的cpu占用過高，或者從節(jié)點頻繁連接。出現(xiàn)這種情況造成的結(jié)果就是主節(jié)點各種資源被嚴(yán)重占用，其中包括但不限于緩沖區(qū)，寬帶，連接等。

為什么會出現(xiàn)主節(jié)點資源被嚴(yán)重占用？

在心跳機(jī)制中，從節(jié)點每秒會發(fā)送一個指令replconf  ack指令到主節(jié)點。 從節(jié)點執(zhí)行了慢查詢，占用大量的cpu 主節(jié)點每秒調(diào)用復(fù)制定時函數(shù)replicationCron，然后從節(jié)點長時間沒有相應(yīng)。

解決方案：

設(shè)置從節(jié)點超時釋放

設(shè)置參數(shù)：repl-timeout

這個參數(shù)默認(rèn)為60秒。超過60秒，釋放slave。

4. 數(shù)據(jù)不一致問題

由于網(wǎng)絡(luò)因素，多個從節(jié)點的數(shù)據(jù)會不一致。這個因素是沒有辦法避免的。

關(guān)于這個問題給出倆個解決方案：

第一個數(shù)據(jù)需要高度一致配置一臺redis服務(wù)器，讀寫都用一臺服務(wù)器，這種方式僅限于少量數(shù)據(jù)，并且數(shù)據(jù)需高度一直。

第二個監(jiān)控主從節(jié)點的偏移量，如果從節(jié)點的延遲過大，暫時屏蔽客戶端對該從節(jié)點的訪問。設(shè)置參數(shù)為slave-serve-stale-data  yes|no。  這個參數(shù)一但設(shè)置就只能響應(yīng)info  slaveof等少數(shù)命令。