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

主從復制的配置要點：

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

這個系統的運行依靠三個主要的機制：

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

主從復制的簡單性質：

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

主從復制的缺點：

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

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

Redis為什么需要主從復制

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

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

Redis主從復制的策略

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

主從全量復制的流程：

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

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

增量復制：

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

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

斷點續傳：

什么是斷點續傳：

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

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

命令格式：psync runid offset

3.2、工作原理：

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

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

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

master服務器維護的offset是存儲在backlog中，msater就是根據slave發送的offset來從backlog中獲取數據的。

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

什么是run_id

run_id是Redis 服務器的隨機標識符，用于 Sentinel 和集群，服務重啟后就會改變;

當slave節點復制時發現和之前的 run_id 不同時，將會對數據進行全量同步。

查看runid

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

什么是偏移量：

通過對比主從節點的復制偏移量，可以判斷主從節點數據是否一致。

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

無磁盤化復制：

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

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

主從復制實現：

主從復制命令：

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

相關配置 ：

master宕機故障

redis將無法執行寫請求，只有slave節點能執行讀請求，影響了系統的可用性

方法1：

隨機找一個節點，執行slaveof no one，使其成為master節點

然后對其他slave節點執行slaveof newMatserIp newMasterPort

方法2：

馬上重啟master節點，它將會重新成為master

方法三：哨兵模式

Redis 復制如何處理 key 的過期

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

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

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

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