Redis 的復制 (replication) 是一種使用和配置起來非常簡單的主從(master-slave)復制，允許 Redis 從服務器成為主服務器的精確副本。以下是關於 Redis 復制的一些重要方面：
- Redis 采用異步復制。從 Redis 2.8 開始，從服務器會周期性地報告從復制流中處理的數據量。 一個主服務器可以擁有多個從服務器。
- 從服務器可以接受其他從服務器的連接。除了連接多個從服務器到同一個主服務器，從服務器也可以連接到其他的從服務器，形成圖狀結構。
- Redis 的復制在主服務器上是非阻塞的。這意味着，當一個或多個從服務器執行初始化同步(initial synchronization)時，主服務器能繼續處理請求。
- Redis 的復制在從服務器上也是非阻塞的。當從服務器正在執行初始化同步時，假如你在
- redis.conf 中進行了相應配置，也能夠繼續使用舊版本的數據集處理請求。另外，你還可以配置當復制流宕(dowm)掉的時候，從服務器返回給客戶端一個錯誤。然而，初始化同步結束后，舊的數據集需要被刪除，新的數據集需要被載入。在這個簡短的窗口期內，從服務器會阻塞到來的連接。
- 復制可以用來支持可伸縮性，用多個從服務器處理只讀查詢(例如，繁重的 SORT 操作可以分配到從服務器上)，也可以僅僅作為數據冗余。
- 可以使用復制來避免主服務器將全部數據集寫到磁盤的開銷：只需要配置你的主服務器的 redis.conf 來防止保存(所有的” 保存” 指令)，然后連接一個不斷復制的從服務器。但是，這種設置下要確保主服務器不會自動重啟(閱讀下一節獲取更多信息)
主服務器關閉持久化時的安全性
當使用了 Redis 的復制時，強烈建議在主服務器上開啟持久化，或者，當不可能開啟持久化時，例如由於關注延遲，實例應該被配置為避免自動重啟。
為了更好的理解為什么關閉了持久化的主服務器被配置為自動重啟是很危險的，查看下面的失敗模型，數據從主服務器以及其所有從服務器上被清除：
- 我們設置節點 A 作為主服務器，關閉了持久化，節點 B 和節點 C 從節點 A 復制。
- A 崩潰了，但是它擁有某個自動重啟系統，重啟了這個進程。但是，由於持久化是被關閉的，這個節點以空的數據集重啟。
- 節點 B 和節點 C 從空的 A 復制，於是它們完全銷毀了他們的數據拷貝。
當 Redis Sentinel 被用於高可用時，主服務器關閉了持久化，並開啟了進程重啟也是很危險的。例如，主務器非常快速的重啟，以至於 Sentinel 沒有檢測到失敗，於是上面描述的失敗模型就發生了。
任何時刻數據安全都是很重要的，要禁止主服務器配置為關閉持久化並自動重啟。
Redis 復制如何工作
當你建立一個從服務器，連接時就會發送一個 SYNC 命令。不管是第一次連接上還是重連接上。
然后主服務器開始在后台保存，並且開始緩沖所有新收到的會修改數據集的命令。當后台保存完成以后，主服務器傳輸數據庫文件給從服務器，從服務器將其保存到磁盤上，然后加載到內存中。然后主服務器開始發送緩沖的命令給從服務器。這是通過命令流完成的，和 Redis 的協議是一樣的格式。
你可以用 telnet 試試。連上一台正在工作的 Redis 的端口，然后發送 SYNC 命令。你會看到大量的傳輸，還有主服務器收到的每條命令被重新發送給了 telnet 會話。
當主從鏈路由於某些原因斷開時，從服務器可以自動重連。如果主服務器收到多個並發的從服務器的同步請求，只會執行一個后台保存來服務所有從服務器。
當主服務器和從服務器斷開后重連上，總是執行一次完整重同步(full resynchronization)。然而，從 Redis 2.8 以后，可以選擇執行部分重同步(partial resynchronization)。
部分重同步
從 Redis 2.8 開始，在復制鏈接斷開后，主服務器和從服務器通常可以繼續復制過程，而不需要一次完整的重同步。
這是通過在主服務器上創建一個復制流的內存緩沖區(in-memory backlog)實現的。主服務器和所有從服務器都記錄一個復制偏移量(offset)和一個主服務器運行 ID(run id)，當鏈接斷掉時，從服務器會重連接，並且請求主服務器繼續復制。假設主服務器的運行 ID 還是一樣的，並且指定的偏移量在復制緩沖區中可用，復制會從中斷的點繼續。如果這兩個條件之一不滿足，將會執行完整重同步(2.8 版之前的正常行為)。
新的部分重同步特性使用的是內部 PSYNC 命令，老的實現采用的是 SYNC 命令。注意，Redis 2.8 的從服務器可以檢測主服務器是否不支持 PSYNC，然后使用 SYNC 代替。
無盤復制
通常，一次完整的重同步需要在磁盤上創建一個 RDB 文件，然后從磁盤重新加載同一個 RDB 來服務從服務器。
由於低速的磁盤，這對主服務器來說是很大壓力的操作。Redis 2.8.18 版本是第一個對無盤復制提供試驗性支持的版本。在這種設置下，子進程直接通過線路(wire)發送 RDB 文件給從服務器，而不需要使用磁盤作為中間存儲。
配置
配置復制簡直小菜一碟：只需要添加下面一行到從服務器配置文件：
slaveof 127.0.0.1 6379
當然，你得把 127.0.0.1 6379 替換成你自己的主服務器 IP 地址(或主機名)和端口。或者，你可以調用 SLAVEOF 命令和主服務器主機，開始與從服務器的一次同步。
有很多參數可以用來調整執行部分重同步主服務器的上的內存復制緩沖區。可以看看 Redis 發布版本中自帶的樣例文件 redis.conf 以獲取更多的信息。
只讀從服務器
從 Redis 2.6 開始，從服務器支持默認開啟的只讀模式。這個行為由 redis.conf 文件中的 slave-read-only 選項控制，可以在運行時使用 CONFIG SET 來開啟和關閉。
只讀從服務器會拒絕所有寫命令，所以寫入數據到從服務器只會引起錯誤。這並不意味着，這個特性打算暴露從服務器實例到互聯網，或者到網絡中不信任的客戶端，因為諸如 DEBUG 和 CONFIG 這樣的管理命令等仍可用。但是，可以通過在 redis.conf 中使用 rename-command 指令來禁止命令，從而改進只讀實例的安全性。
你可能很好奇，為什么需要能夠反轉只讀設置，使得從服務器實例能夠成為寫操作的目標。盡管這些寫入的數據會在從服務器和主服務器重同步時，或者從服務器重啟時被丟棄，還是有一些存儲一些短暫的數據到可寫的從服務器的合理場景。例如，客戶端可以存儲一些主服務器的可達性信息來調整故障轉移(failover)策略。
認證主服務器
如果你的主服務器通過 requirepass 而有一個密碼，很容易配置從服務器在所有同步操作中使用這個密碼。
要做到這個，在一個運行的實例上，使用 redis-cli 並鍵入：
config set masterauth <password>
要永久設置這個，添加這個倒你的配置文件中：
masterauth <password>
N 個副本才能寫
從 Redis 2.8 開始，可以設置 Redis 主服務器在當前至少擁有 N 個從服務器的連接的情況下，才能接受寫請求。
然而，由於 Redis 使用異步復制，不能保證從服務器真正收到了一個給定的寫請求，於是總是有一個數據丟失的窗口期。
下面是這個特性是如何運作的：
- Redis 從服務器每秒種 ping 主服務器，上報處理完的復制流的數據量。
- Redis 主服務器記錄上一次從每一個從服務收到 ping 的時間。
- 用戶可以配置最小從服務器數量，每台從服務器擁有一個不大於最大秒數的滯后(lag)。
如果有至少 N 個小於 M 秒滯后的從服務器，寫請求才會被接受。
你可能會認為這個像 CAP 理論中較寬松版本的”C”，不能保證指定寫的一致性，但是至少數據丟失的時間窗口被限制在一個指定的秒數內。
如果條件不滿足，主服務器會返回一個錯誤，並且不會接受寫請求。
這個特性有兩個配置參數：
min-slaves-to-write <number of slaves> min-slaves-max-lag <number of seconds>