Redis-複製

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>