以下是關於 Redis 複製功能的幾個重要方面: |
|
|
|
|
|
+- Redis 使用異步複製。 |
|
|
+ 從 Redis 2.8 開始, |
|
|
+ 從服務器會以每秒一次的頻率向主服務器報告複製流(replication stream)的處理進度。 |
|
|
+ |
|
|
- 一個主服務器可以有多個從服務器。 |
|
|
|
|
|
- 不僅主服務器可以有從服務器, |
|
@@ -76,8 +80,43 @@ Redis 支持簡單且易用的主從複製(master-slave replication)功能 |
|
|
就可以處理所有這些從服務器的同步請求。 |
|
|
|
|
|
從服務器可以在主從服務器之間的連接斷開時進行自動重連, |
|
|
-在重連成功之後, |
|
|
-從服務器需要重新執行一次完整的重同步(resync)操作。 |
|
|
+在 Redis 2.8 版本之前, |
|
|
+斷線之後重連的從服務器總要執行一次完整重同步(full resynchronization)操作, |
|
|
+但是從 Redis 2.8 版本開始, |
|
|
+從服務器可以根據主服務器的情況來選擇執行完整重同步還是部分重同步(partial resynchronization)。 |
|
|
+ |
|
|
+ |
|
|
+部分重同步 |
|
|
+---------------------------------------- |
|
|
+ |
|
|
+從 Redis 2.8 開始, |
|
|
+在網絡連接短暫性失效之後, |
|
|
+主從服務器可以嘗試繼續執行原有的複製進程(process), |
|
|
+而不一定要執行完整重同步操作。 |
|
|
+ |
|
|
+這個特性需要主服務器爲被髮送的複製流創建一個內存緩衝區(in-memory backlog), |
|
|
+並且主服務器和所有從服務器之間都記錄一個複製偏移量(replication offset)和一個主服務器 ID (master run id), |
|
|
+當出現網絡連接斷開時, |
|
|
+從服務器會重新連接, |
|
|
+並且向主服務器請求繼續執行原來的複製進程: |
|
|
+ |
|
|
+- 如果從服務器記錄的主服務器 ID 和當前要連接的主服務器的 ID 相同, |
|
|
+ 並且從服務器記錄的偏移量所指定的數據仍然保存在主服務器的複製流緩衝區裏面, |
|
|
+ 那麼主服務器會向從服務器發送斷線時缺失的那部分數據, |
|
|
+ 然後複製工作可以繼續執行。 |
|
|
+ |
|
|
+- 否則的話, |
|
|
+ 從服務器就要執行完整重同步操作。 |
|
|
+ |
|
|
+Redis 2.8 的這個部分重同步特性會用到一個新增的 ``PSYNC`` 內部命令, |
|
|
+而 Redis 2.8 以前的舊版本只有 :ref:`SYNC` 命令, |
|
|
+不過, |
|
|
+只要從服務器是 Redis 2.8 或以上的版本, |
|
|
+它就會根據主服務器的版本來決定到底是使用 ``PSYNC`` 還是 :ref:`SYNC` : |
|
|
+ |
|
|
+- 如果主服務器是 Redis 2.8 或以上版本,那麼從服務器使用
``PSYNC`` 命令來進行同步。 |
|
|
+ |
|
|
+- 如果主服務器是 Redis 2.8 之前的版本,那麼從服務器使用 :ref:`SYNC` 命令來進行同步。 |
|
|
|
|
|
|
|
|
配置 |
|
@@ -136,7 +175,7 @@ Redis 支持簡單且易用的主從複製(master-slave replication)功能 |
|
|
從而實現故障轉移(failover)策略。 |
|
|
|
|
|
|
|
|
-設置從服務器,讓它通過主服務器的身份驗證 |
|
|
+從服務器相關配置 |
|
|
----------------------------------------------- |
|
|
|
|
|
如果主服務器通過 ``requirepass`` 選項設置了密碼, |
|
@@ -156,3 +195,55 @@ Redis 支持簡單且易用的主從複製(master-slave replication)功能 |
|
|
:: |
|
|
|
|
|
masterauth <password> |
|
|
+ |
|
|
+另外還有幾個選項, |
|
|
+它們和主服務器執行部分重同步時所使用的複製流緩衝區有關, |
|
|
+詳細的信息可以參考 Redis 源碼中附帶的 ``redis.conf`` 示例文件。 |
|
|
+ |
|
|
+ |
|
|
+主服務器只在有至少 N 個從服務器的情況下,才執行寫操作 |
|
|
+------------------------------------------------------- |
|
|
+ |
|
|
+從 Redis 2.8 開始, |
|
|
+爲了保證數據的安全性, |
|
|
+可以通過配置, |
|
|
+讓主服務器只在有至少 N 個當前已連接從服務器的情況下, |
|
|
+才執行寫命令。 |
|
|
+ |
|
|
+不過, |
|
|
+因爲 Redis 使用異步複製, |
|
|
+所以主服務器發送的寫數據並不一定會被從服務器接收到, |
|
|
+因此, |
|
|
+數據丟失的可能性仍然是存在的。 |
|
|
+ |
|
|
+以下是這個特性的運作原理: |
|
|
+ |
|
|
+- 從服務器以每秒一次的頻率 PING 主服務器一次, |
|
|
+ 並報告複製流的處理情況。 |
|
|
+ |
|
|
+- 主服務器會記錄各個從服務器最後一次向它發送 PING 的時間。 |
|
|
+ |
|
|
+- 用戶可以通過配置, |
|
|
+ 指定網絡延遲的最大值 ``min-slaves-max-lag`` , |
|
|
+ 以及執行寫操作所需的至少從服務器數量 ``min-slaves-to-write`` 。 |
|
|
+ |
|
|
+如果至少有 ``min-slaves-to-write`` 個從服務器, |
|
|
+並且這些服務器的延遲值都少於 ``min-slaves-max-lag`` 秒, |
|
|
+那麼主服務器就會執行客戶端請求的寫操作。 |
|
|
+ |
|
|
+你可以將這個特性看作 CAP 理論中的 C 的條件放寬版本: |
|
|
+儘管不能保證寫操作的持久性, |
|
|
+但起碼丟失數據的窗口會被嚴格限制在指定的秒數中。 |
|
|
+ |
|
|
+另一方面, |
|
|
+如果條件達不到 ``min-slaves-to-write`` 和
``min-slaves-max-lag`` 所指定的條件, |
|
|
+那麼寫操作就不會被執行, |
|
|
+主服務器會向請求執行寫操作的客戶端返回一個錯誤。 |
|
|
+ |
|
|
+以下是這個特性的兩個選項和它們所需的參數: |
|
|
+ |
|
|
+- ``min-slaves-to-write <number of slaves>`` |
|
|
+ |
|
|
+- ``min-slaves-max-lag <number of seconds>`` |
|
|
+ |
|
|
+詳細的信息可以參考 Redis 源碼中附帶的 ``redis.conf`` 示例文件。 |