Redis複製非常易於使用和配置主從複製，所謂主從複製即允許slave服務是master服務的正確考貝，關於Redis複製有以下幾個要點：
- Redis使用異步複製。然而，從Redis 2.8開始，slave服務器定期的從複製流獲取數據。
- 一個master服務可以有多個slave服務。
- slave從服務可以接收來自其他slave從服務的連接。除了大量slave從服務連接到master服務外，slaves也可以在層疊狀結構中被其他從服務連接。
- Redis複製在master一方是無阻塞的。這表示當一個或者多個slaves執行初始同步時，master服務器將持續處理請求。
- Redis複製在slave一方也是無阻塞的。儘管slave正在執行初始同步，如果你在Redis配置文件中（redis.conf）設置了，那麼它就同樣可以使用老版本的數據處理請求。否則，你可以配置Redis在其同步時返回一個錯誤給客戶端請求。然而，在初始同步以後，老的數據集必須被刪除，新的數據必須被加載，此期間，slave將阻塞客戶端的連接（如果是非常大的數據集可以達到好幾秒）。
- Redis複製同時也是可擴展的，爲了擁有多個slaves用於只讀查詢或者是數據冗餘。
- 也可以使用Redis複製來避免master將全部的數據集持久化到磁盤的消耗：一個典型的涉及到配置你的redis.conf來避免持久化到硬盤的技術，然後連接到配置的slave服務以時時保存，或者啓用AOF。但是這種設置必須小心處理，因爲一個master服務是以空的數據集重啓的：如果slaves試圖從他同步數據，那麼slaves數據集也將會被清空。
關閉持久化後複製的安全性
Redis複製被使用的設置裏，強烈建議開啓master的持久化功能，或者因爲延遲等問題不能開啓時，Redis實例要被配置爲操作系統重啓避免自動重啓。
爲了更好的理解爲什麼master持久化關閉後配置成自動重啓是危險的，查看如下master和其所有slaves數據被擦去的失敗模型：
1.我們設置節點A作爲master，關閉了其持久化功能，節點B和節點C從節點A複製數據集。
2.然後系統崩潰了，但是它有一些自動重啓的系統來重啓Redis進程。但因爲持久化關閉了，此節點將以空數據集重啓。
3.然後節點B與節點C從A同步數據，所以節點B與節點C的數據集也空了。
任何時候數據安全都是重要的，如果Redis複製用於配置禁用持久化的master，必須也禁用Redis實例的自動重啓功能。
Redis複製怎麼工作
如果你設置了一個slave從服務，連接它的時候發送個PSYNC命令。
如果這是重連並且master擁有足夠的儲備，那麼只有並異（slave丟失的）會被髮送，否則一個叫做full resynchronization的操作被觸發。
當full resynchronization被觸發時，master服務會開啓一個後臺進保存進程用於生成一個RDB文件，同時開始緩存從客戶接收的所有新的寫操作命令，當後臺保存完成後，master遷移RDB文件到slave，slave接收RDB然後存儲到磁盤並且加載到內存。然後master將所有緩存的命令發送給slave，以一個命令流的方式發送，並且是以Redis協議自身相同的格式發送。
master-slave鏈接由於某些原因斷開時，slaves能夠自動重連。如果master接收到多個同時發生的slave同步請求，它會開啓一個單獨的後臺保存進程給它們提供服務。
部分重新同步
從Redis2.8開始，master和slave通常可以在複製鏈接斷開後繼續複製進程，而不需要再次請求一次完全再次同步操作。
這項工作是通過在master這邊內存中創建一個複製流的備份。master和所有的slaves商定一個複製偏移量和一個master運行ID，所以當連接斷開時，slave會重新連接並請求master繼續同步。假設master運行ID是一致的，並且指定的複製偏移量是在複製備份中是可用的，那麼同步將從其此點也即上次失敗的位置重新開始。如果兩個條件中的任何一個不滿足，那麼完整的重新同步操作將被執行。因爲master運行ID是不會持久化到磁盤的，所以當slave重新啓動時將會觸發完全同步操作。
新的部分重新同步功能內部使用PSYNC命令，而老的實現則使用SYNC命令。
注：Redis slave能夠檢查是否正在會話的服務支持PSYNC命令，如果不支持，以SYNC命令代替。
無磁盤複製
正常情況下，一個完全的再同步操作需要在磁盤上創建一個RDB文件，然後再從磁盤加載此RDB文件用於給slaves反饋數據。
在慢磁盤情況下，這樣的操作對於Redis來說是個很有壓力的操作。Redis2.8.18是第一個支持無磁盤複製的版本。此種設置下，子進程會直接將RDB文件發送給slaves，而不需要使用磁盤作爲中間存儲。
配置
配置slave副本很簡單，僅僅需要下面一行加入到slave配置文件就可以：
slaveof 192.168.1.1 6379
當然你需要把192.168.1.1 6379 替換爲你的master IP地址（或者主機名）和端口號。另外，你也可以調用SLAVEOF命令，然後master主機就會對此slave進行同步。
無磁盤複製可以通過repl-diskless-sync配置指令啓用。且於開始傳輸前等待更多slaves連接的延遲由repl-diskless-sync-delay配置指令控制。詳細查看redis配置指令。
只讀slave
從Redis2.6開始，slaves支持默認啓用的只讀模式。此行爲是由redis.conf文件中的配置指令slave-read-only控制，或者可以通過CONFIG SET命令啓用或者禁用。
只讀slaves拒絕所有的寫操作命令，所以不可能發生發生在slave進行寫操作錯誤。這不是表示此機制的設計目的是爲將slave實例暴露在不可信客戶端存在的網絡環境中，因爲一些像DEBUG或者CONFIG這樣的管理員命令是依然可用的（危險依然存在）。但是，只讀slave的安全性可以通過redis.conf文件中rename-command指令配置提高。
你可能會好奇爲什麼只讀slave可以回覆爲可寫slave和爲什麼有一些可寫slave實例。儘管那些可寫特性在主從同步或者slave重啓時會被清除，但是在可寫的slave中存存放臨時數據少量使用場景同樣也是合法的。
例如執行比較慢的set或者zset操作和將它們存儲在本地key空間都是可寫slave實例的使用場景。
但是要注意，在Redis 4.0之前可寫slaves是不能夠處理還有生存時間的未過期的keys的。也就是說如果你使用EXPIRE命令或者其他命令給key設置了最大的生存時間，那麼可寫slaves將忽略此key，並且你在使用讀相關命令訪問他的時候，它也是不可見的。你只能在keys的計數中看到，並且它仍然使用內存。所以4.0之前的可寫slaves在處理含有生存時間的Key時是有問題的。
配置slave到master的認證
如果master通過requirepass指令指定了密碼，那麼配置slave認證操作可如下：
使用客戶端運行時配置：
config set masterauth
只有不少於N個副本才進行寫操作
從Redis2.8開始，可以允許配置當前至少N個slaves連接到master時才接收寫操作請求。
但是，因爲Redis使用的是異步複製，不可能確保slave一定能接收到master指向它的複製流，所以總是有一個數據丟失的窗口。如下是此機制的工作原理：
- slaves每秒都ping master。
- master記錄每個slave ping的最後時間。
- 用戶配置一個最小數目的slave（N），限於不大於一個最大秒數的遲滯時間（M）。
如果少於M秒內有至少N個slave連接，master將接受此寫操作。如果不滿足條件，則返回錯誤。
此操作由兩個配置指令控制：
- min-slaves-to-write
- min-slaves-max-lag
redis複製怎麼處理keys的過期
Redis過期機制允許keys擁有存活時間限制，此機制依賴於redis實例的計時功能，但是Redis slaves要確保正確的複製含有過期設置的keys，即使在這些Keys被使用Lua腳本修改的時候。
要實現此功能需要，Redis不能依賴於master與slave的同步時鐘，因爲這不能解決問題並且會導致競爭條件和不同的數據集，所以Redis使用了三項主要技術以保證含過期時間的keys的複製正常生活：
- Slaves實例不對Keys進行過期操作，而是等待master過期這些Keys。當Master對一個key進行過期操作（或者由於LRU算法進行刪除）時，它將同時給它所有的slaves發送一個刪除命令（DEL）。
- 儘管Master驅動過期，但是有時候slaves實例的內存中還是有可能存在理論上已過期的keys，原因是master不能及時的發送DEL命令。爲了處理此種情況，slaves實例則會依據本地時鐘回覆對於理論上已過期的Keys的查詢操作說key已不存在，即與此時數據集不一致。
- 在LUA腳本執行期間，不會有keys過期操作執行。當一個LUA腳本運行時，從概念上講master處時間是凍結的，用於保證在腳本執行整個過程中keys要麼是存在的要麼是不存的，防止腳本執行過程中keys過期。
注：一旦一個slave實例轉換成master，它能夠獨立進行過期keys操作，不需要老的master提供任何幫助。
