Redis 復制功能的幾個重要方面：
1. 一個Master可以有多個Slave；
2. Redis使用異步復制。從2.8開始，Slave會周期性（每秒一次）發起一個Ack確認復制流（replication stream）被處理進度；
3. 不僅主服務器可以有從服務器， 從服務器也可以有自己的從服務器， 多個從服務器之間可以構成一個圖狀結構；
4. 復制在Master端是非阻塞模式的，這意味著即便是多個Slave執行首次同步時，Master依然可以提供查詢服務；
5. 復制在Slave端也是非阻塞模式的：如果你在redis.conf做了設置，Slave在執行首次同步的時候仍可以使用舊數據集提供查詢；你也可以配置為當Master與Slave失去聯系時，讓Slave返回客戶端一個錯誤提示；
6. 當Slave要刪掉舊的數據集，並重新加載新版數據時，Slave會阻塞連接請求（一般發生在與Master斷開重連後的恢復階段）；
7. 復制功能可以單純地用於數據冗余（data redundancy），也可以通過讓多個從服務器處理只讀命令請求來提升擴展性（scalability）： 比如說， 繁重的 SORT 命令可以交給附屬節點去運行。
8. 可以通過修改Master端的redis.config來避免在Master端執行持久化操作（Save），由Slave端來執行持久化。

Redis復制工作原理：
1. 如果設置了一個Slave，無論是第一次連接還是重連到Master，它都會發出一個SYNC命令；
2. 當Master收到SYNC命令之後，會做兩件事：
a) Master執行BGSAVE，即在後臺保存數據到磁盤（rdb快照文件）；
b) Master同時將新收到的寫入和修改數據集的命令存入緩沖區（非查詢類）；
3. 當Master在後臺把數據保存到快照文件完成之後，Master會把這個快照文件傳送給Slave，而Slave則把內存清空後，加載該文件到內存中；
4. 而Master也會把此前收集到緩沖區中的命令，通過Reids命令協議形式轉發給Slave，Slave執行這些命令，實現和Master的同步；
5. Master/Slave此後會不斷通過異步方式進行命令的同步，達到最終數據的同步一致；
6. 需要註意的是Master和Slave之間一旦發生重連都會引發全量同步操作。但在2.8之後版本，也可能是部分同步操作。
部分復制
2.8開始，當Master和Slave之間的連接斷開之後，他們之間可以采用持續復制處理方式代替采用全量同步。
Master端為復制流維護一個內存緩沖區（in-memory backlog），記錄最近發送的復制流命令；同時，Master和Slave之間都維護一個復制偏移量(replication offset)和當前Master服務器ID（Master run id）。當網絡斷開，Slave嘗試重連時：
a. 如果MasterID相同（即仍是斷網前的Master服務器），並且從斷開時到當前時刻的歷史命令依然在Master的內存緩沖區中存在，則Master會將缺失的這段時間的所有命令發送給Slave執行，然後復制工作就可以繼續執行了；
b. 否則，依然需要全量復制操作；
Redis 2.8 的這個部分重同步特性會用到一個新增的 PSYNC 內部命令， 而 Redis 2.8 以前的舊版本只有 SYNC 命令， 不過， 只要從服務器是 Redis 2.8 或以上的版本， 它就會根據主服務器的版本來決定到底是使用 PSYNC 還是 SYNC ：
如果主服務器是 Redis 2.8 或以上版本，那麽從服務器使用 PSYNC 命令來進行同步。
如果主服務器是 Redis 2.8 之前的版本，那麽從服務器使用 SYNC 命令來進行同步。
Redis 復制機制
首先是slave端，對於slave端來說，主從復制主要經歷四個階段：
第一階段：與master建立連接
第二階段：向master發起同步請求（SYNC）
第三階段：接受master發來的RDB數據
第四階段：載入RDB文件
下面我們就通過一個圖來概述在每一個階段中，slave究竟做了些什麽：
關於上圖，有一點說明下：redis接收到slaveof master_host master_port命令後並沒有馬上與master建立連接，而是當執行服務器例行任務serverCron，發現自己正處於REDIS_REPL_CONNECT狀態，這時才真正的向maser發起連接，偽代碼：

Python代碼

def serverCron(): # 服務器處於REDIS_REPL_CONNECT狀態 if redisServer.repl_state == REDIS_REPL_CONNECT: # 向master發起連接 connectWithMaster() # 其他例行任務（省略）...

接著我們來看下主從復制過程中，master這邊的流程是如何，在具體看細節之前，我們先綜合來看master這邊主要做的幾件事情：
看完這個圖，你也許會有以下幾個疑問：
1. 為什麽在master發送完RDB文件後，還要定期的向slave發送PING命令？
2. 在發送完RDB文件之後，master發送的“變更”命令又是什麽，有什麽用？
在回答問題之前1，我們先回答問題2：
master保存RDB文件是通過一個子進程進行的，所以master依然可以處理客戶端請求而不被阻塞，但這也導致了在保存RDB文件期間，“鍵空間”可能發生變化（譬如接收到一個客戶端請求，執行"set name diaocow"命令），因此為了保證數據同步的一致性，master會在保存RDB文件期間，把接受到的這些可能變更數據庫“鍵空間”的命令保存下來，然後放到每個slave的回復列表中，當RDB文件發送完master會發送這些回復列表中的內容，並且在這之後，如果數據庫發生變更，master依然會把變更的命令追加到回復列表發送給slave，這樣就可以保證master和slave數據的一致性！相關偽代碼：

Python代碼

def processCommand(cmd, argc, argv): # 處理命令 call(cmd, argc, argv) # 如果該命令造成數據庫鍵空間變化and當前redis是一個master，則同步變更命令 if redisServer.update_ey_space and len(redisServer.slaves) > 0: replicationFeedSlaves(cmd, argc, argv) def replicationFeedSlaves(cmd, argc,www.baidu620.com/ argv): # 把變更命令發送給每一個處於：REDIS_REPL_WAIT_BGSAVE_END狀態的slave節點 for slave in redisServer.slaves: if slave.replstate www.dongfan178.com== REDIS_REPL_WAIT_BGSAVE_START: continue www.dashuju178.com slave.updateNotify(cmd, argc, argv)

由於在發送完RDB文件之後，master會不定時的給slave發送“變更”命令，可能過1s，也可能過1小時，所以為了防止slave無意義等待（譬如master已經掛掉的情況），master需要定時發送“保活”命令PING，以此告訴slave：我還活著，不要中斷與我的連接
現在我們就看下，當master接受到slave發送的sync同步命令後究竟發生了哪些事：
上圖看似分支復雜，但我們抓住以下幾點即可：
1.保存RDB文件是在一個子進程中進行的；
2.如果master已經在保存RDB文件，但是沒有客戶端正在等待這次BGSAVE，新添加的slave需要等到下次BGSAVE，而不能直接使用這次生成的RDB文件（原因圖中已經說明）
3.master會定期檢查RDB文件是否保存完畢（時間事件serverCron）；
接下來我們看下，master是如何給每一個slave發送RDB文件的：
好了，至此我們已經分析完在主從復制過程中，master和slave兩邊分別是怎麽一個處理流程;最後，我繪制了一個圖，綜述了主從復制這一過程（我們可以邊看圖，邊回憶其中的具體細節）：PS：在主從復制過程中，任何一步發生錯誤，都會導致整個過程重頭開始，所以若RDB文件很大又或是此時正處在業務高峰期，對系統性能將會有非常大的影響！
Redis 復制操作
一、Redis實現復制很簡單，主要有下面兩個方法
1、從機器的redis.conf添加slaveof 主IP 端口，然後帶上配置文件啟動server
# src/redis-server redis.conf
2、從機器啟動後在命令裏打入slaveof 主IP 端口，這裏是全局命令
127.0.0.1 6379> salveof 192.168.10.10 6379
二、關閉同步（從機器）
# src/redis-server no one

Redis 復制功能的幾個重要方面