使用和配置主從復(fù)制，能使得從 Redis 服務(wù)器( slave)能精確得復(fù)制主 Redis 服務(wù)器( master)的內(nèi)容。每次當(dāng) slave 和 master 之間的連接斷開時， slave 會自動重連到 master 上，并且無論這期間 master 發(fā)生了什么， slave 都將嘗試讓自身成為 master 的精確副本。

主從復(fù)制的配置要點：

• 配從庫不配主，從庫配置：slaveof 主庫IP 主庫端口
• 查看redis的配置信息：info replication

這個系統(tǒng)的運行依靠三個主要的機制：

• 當(dāng)一個 master 實例和一個 slave 實例連接正常時， master 會發(fā)送一連串的命令流來保持對 slave 的更新，以便于將自身數(shù)據(jù)集的改變復(fù)制給 slave ：包括客戶端的寫入、key 的過期或被逐出等等。
• 當(dāng) master 和 slave 之間的連接斷開之后，因為網(wǎng)絡(luò)問題、或者是主從意識到連接超時， slave 重新連接上 master 并會嘗試進行部分重同步：這意味著它會嘗試只獲取在斷開連接期間內(nèi)丟失的命令流。
• 當(dāng)無法進行部分重同步時， slave 會請求進行全量重同步。這會涉及到一個更復(fù)雜的過程，例如 master 需要創(chuàng)建所有數(shù)據(jù)的快照，將之發(fā)送給 slave ，之后在數(shù)據(jù)集更改時持續(xù)發(fā)送命令流到 slave 。

主從復(fù)制的簡單性質(zhì)：

• 一個master可以有多個slave
• 每個slave只能有一個master
• 每個slave也可以有自己的多個slave
• 數(shù)據(jù)流是單向的，從master到slave

主從復(fù)制的缺點：

由于所有的寫操作都是先在Master上操作，然后同步更新到Slave上，所以從Master同步到Slave服務(wù)器有一定的延遲，當(dāng)系統(tǒng)很繁忙的時候，延遲問題會更加嚴重，Slave機器數(shù)量的增加也會使這個問題更加嚴重。

如果master宕機了，默認情況下不會在slave節(jié)點中自動選擇一個master(不能進行寫操作)，所以有哨兵和集群的概念。

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

使用Redis主從復(fù)制的原因主要是單臺Redis節(jié)點存在以下的局限性：

• Redis雖然讀寫的速度都很快，單節(jié)點的Redis能夠支撐QPS大概在5w左右，如果上千萬的用戶訪問，Redis就承載不了，成為了高并發(fā)的瓶頸。
• 單節(jié)點的Redis不能保證高可用，當(dāng)Redis因為某些原因意外宕機時，會導(dǎo)致緩存不可用。
• CPU的利用率上，單臺Redis實例只能利用單個核心，這單個核心在面臨海量數(shù)據(jù)的存取和管理工作時壓力會非常大。

Redis主從復(fù)制的策略

從總體上來說，Redis主從復(fù)制的策略就是：當(dāng)主從服務(wù)器剛建立連接的時候，進行全量同步;全量復(fù)制結(jié)束后，進行增量復(fù)制。當(dāng)然，如果有需要，slave 在任何時候都可以發(fā)起全量同步。

主從全量復(fù)制的流程：

Redis全量復(fù)制一般發(fā)生在Slave初始化階段，這時Slave需要將Master上的所有數(shù)據(jù)都復(fù)制一份，具體步驟如下：

• slave服務(wù)器連接到master服務(wù)器，便開始進行數(shù)據(jù)同步，發(fā)送psync命令(Redis2.8之前是sync命令)
• master服務(wù)器收到psync命令之后，開始執(zhí)行bgsave命令生成RDB快照文件并使用緩存區(qū)記錄此后執(zhí)行的所有寫命令
• -如果master收到了多個slave并發(fā)連接請求，它只會進行一次持久化，而不是每個連接都執(zhí)行一次，然后再把這一份持久化的數(shù)據(jù)發(fā)送給多個并發(fā)連接的slave。如果RDB復(fù)制時間超過60秒(repl-timeout)，那么slave服務(wù)器就會認為復(fù)制失敗，可以適當(dāng)調(diào)節(jié)大這個參數(shù)
• master服務(wù)器bgsave執(zhí)行完之后，就會向所有Slava服務(wù)器發(fā)送快照文件，并在發(fā)送期間繼續(xù)在緩沖區(qū)內(nèi)記錄被執(zhí)行的寫命令
• client-output-buffer-limit slave 256MB 64MB 60，如果在復(fù)制期間，內(nèi)存緩沖區(qū)持續(xù)消耗超過64MB，或者一次性超過256MB，那么停止復(fù)制，復(fù)制失敗
• slave服務(wù)器收到RDB快照文件后，會將接收到的數(shù)據(jù)寫入磁盤，然后清空所有舊數(shù)據(jù)，在從本地磁盤載入收到的快照到內(nèi)存中，同時基于舊的數(shù)據(jù)版本對外提供服務(wù)。
• slave服務(wù)器完成對快照的載入，開始接收命令請求，并執(zhí)行來自主服務(wù)器緩沖區(qū)的寫命令;
• 如果slave 節(jié)點開啟了AOF，那么會立即執(zhí)行BGREWRITEAOF，重寫AOF

增量復(fù)制：

Redis的增量復(fù)制是指在初始化的全量復(fù)制并開始正常工作之后，master服務(wù)器將發(fā)生的寫操作同步到slave服務(wù)器的過程，

增量復(fù)制的過程主要是master服務(wù)器每執(zhí)行一個寫命令就會向slave服務(wù)器發(fā)送相同的寫命令，slave服務(wù)器接收并執(zhí)行收到的寫命令。

斷點續(xù)傳：

什么是斷點續(xù)傳：

slave與master能夠在網(wǎng)絡(luò)連接斷開重連后，只從中斷處繼續(xù)進行復(fù)制，而不必重新同步，這就是所謂的斷點續(xù)傳。

斷電續(xù)傳這個新特性使用psync命令，master服務(wù)器收到slave發(fā)送的psync命令后，會根據(jù)自身的情況做出對應(yīng)的處理，可能是FULLRESYNC runid offset觸發(fā)全量復(fù)制，也可能是CONTINUE觸發(fā)增量復(fù)制

命令格式：psync runid offset

3.2、工作原理：

(1)master服務(wù)器在內(nèi)存緩沖區(qū)中給每個slave服務(wù)器都維護了一份同步備份日志(in-memory backlog)，緩存最近一段時間的數(shù)據(jù)，默認大小1m，如果超過這個大小就會清理掉。

(2)同時，master 和 slave 服務(wù)器都維護了一個復(fù)制偏移量(replication offset)和 master線程ID(master run id)，每個slave服務(wù)器在跟master服務(wù)器進行同步時都會攜帶master run id 和 最后一次同步的復(fù)制偏移量offset，通過offset可以知道主從之間的數(shù)據(jù)不一致的情況。

(3)當(dāng)連接斷開時，slave服務(wù)器會重新連接上master服務(wù)器，然后請求繼續(xù)復(fù)制。假如主從服務(wù)器的兩個master run id相同，并且指定的偏移量offset在同步備份日志中還有效，復(fù)制就會從上次中斷的點開始繼續(xù)。如果其中一個條件不滿足，就會進行完全重新同步，因為主運行id不保存在磁盤中，如果從服務(wù)器重啟的話就只能進行完全同步了。

master服務(wù)器維護的offset是存儲在backlog中，msater就是根據(jù)slave發(fā)送的offset來從backlog中獲取數(shù)據(jù)的。

(4)在部分同步過程中，master會將本地記錄的同步備份日志中記錄的指令依次發(fā)送給slave服務(wù)器從而達到數(shù)據(jù)一致。

什么是run_id

run_id是Redis 服務(wù)器的隨機標(biāo)識符，用于 Sentinel 和集群，服務(wù)重啟后就會改變;

當(dāng)slave節(jié)點復(fù)制時發(fā)現(xiàn)和之前的 run_id 不同時，將會對數(shù)據(jù)進行全量同步。

查看runid

redis-cli -p 6379 info server | grep run
run_id:345dda992e5064bc80e01f96ea90f729b722b2ea

什么是偏移量：

通過對比主從節(jié)點的復(fù)制偏移量，可以判斷主從節(jié)點數(shù)據(jù)是否一致。

• 參與復(fù)制的主從節(jié)點都會維護自身的復(fù)制偏移量。主節(jié)點(master)在處理完寫命令后，會把命令的字節(jié)長度做累加記錄，統(tǒng)計信息在info replication中的master_repl_offset指標(biāo)中。
• 從節(jié)點每秒上報自身的復(fù)制偏移量給主節(jié)點，因此主節(jié)點也會保存從節(jié)點的復(fù)制偏移量
• 從節(jié)點在接收到主節(jié)點發(fā)送的命令后，也會累加記錄自身的偏移量。統(tǒng)計在info replication中的slave_repl_offset指標(biāo)中

無磁盤化復(fù)制：

在前面全量復(fù)制的過程中，master會將數(shù)據(jù)保存在磁盤的rdb文件中然后發(fā)送給slave服務(wù)器，但如果master上的磁盤空間有限或者是使用比較低速的磁盤，這種操作會給master服務(wù)器帶來較大的壓力，那怎么辦呢?在Redis2.8之后，可以通過無盤復(fù)制來達到目的，由master直接開啟一個socket，在內(nèi)存中創(chuàng)建RDB文件，再將rdb文件發(fā)送給slave服務(wù)器，不使用磁盤作為中間存儲。(無盤復(fù)制一般應(yīng)用在磁盤空間有限但是網(wǎng)絡(luò)狀態(tài)良好的情況下)

repl-diskless-sync ：是否開啟無磁盤復(fù)制
repl-diskless-sync-delay：等待一定時長再開始復(fù)制，因為要等更多slave重新連接過來

主從復(fù)制實現(xiàn)：

主從復(fù)制命令：

#在希望成為slave的節(jié)點中執(zhí)行命令(改換門庭)
slaveof ${masterIP} ${masterPort}
#此過程會異步第將master節(jié)點中的數(shù)據(jù)全量復(fù)制到當(dāng)前節(jié)點中(如果使用命令模式，只有當(dāng)次生效，例：重啟)
#主從復(fù)制(配從庫，不配主庫
repliceof ${masterIP} ${masterPort}
#在不希望作為slave的節(jié)點中執(zhí)行以下命令
salveof no one
#查看當(dāng)前節(jié)點是否主從
info replication
#從機訪問主機的通行密碼，如果master設(shè)置了登錄密碼
masterauth ${password}

相關(guān)配置 ：

master宕機故障

redis將無法執(zhí)行寫請求，只有slave節(jié)點能執(zhí)行讀請求，影響了系統(tǒng)的可用性

方法1：

隨機找一個節(jié)點，執(zhí)行slaveof no one，使其成為master節(jié)點

然后對其他slave節(jié)點執(zhí)行slaveof newMatserIp newMasterPort

方法2：

馬上重啟master節(jié)點，它將會重新成為master

方法三：哨兵模式

Redis 復(fù)制如何處理 key 的過期

Redis 的過期機制可以限制 key 的生存時間。此功能取決于 Redis 實例計算時間的能力，但是，即使使用 Lua 腳本更改了這些 key，Redis slaves 也能正確地復(fù)制具有過期時間的 key。

為了實現(xiàn)這樣的功能，Redis 不能依靠主從使用同步時鐘，因為這是一個無法解決的并且會導(dǎo)致 race condition 和數(shù)據(jù)集不一致的問題，所以 Redis 使用三種主要的技術(shù)使過期的 key 的復(fù)制能夠正確工作：

• slave 不會讓 key 過期，而是等待 master 讓 key 過期。當(dāng)一個 master 讓一個 key 到期(或由于 LRU 算法將之驅(qū)逐)時，它會合成一個 DEL 命令并傳輸?shù)剿械?slave。
• 但是，由于這是 master 驅(qū)動的 key 過期行為，master 無法及時提供 DEL 命令，所以有時候 slave 的內(nèi)存中仍然可能存在在邏輯上已經(jīng)過期的 key 。為了處理這個問題，slave 使用它的邏輯時鐘以報告只有在不違反數(shù)據(jù)集的一致性的讀取操作(從主機的新命令到達)中才存在 key。用這種方法，slave 避免報告邏輯過期的 key 仍然存在。在實際應(yīng)用中，使用 slave 程序進行縮放的 HTML 碎片緩存，將避免返回已經(jīng)比期望的時間更早的數(shù)據(jù)項。
• 在Lua腳本執(zhí)行期間，不執(zhí)行任何 key 過期操作。當(dāng)一個Lua腳本運行時，從概念上講，master 中的時間是被凍結(jié)的，這樣腳本運行的時候，一個給定的鍵要么存在要么不存在。這可以防止 key 在腳本中間過期，保證將相同的腳本發(fā)送到 slave ，從而在二者的數(shù)據(jù)集中產(chǎn)生相同的效果。

一旦一個 slave 被提升為一個 master ，它將開始獨立地過期 key，而不需要任何舊 master 的幫助。