深入學習Redis的高可用特性“持久化”

程式設計迷思

本文将先說明上述幾種技術分别解決了 Redis 高可用的什麼問題，然後詳細介紹 Redis 的持久化技術，主要是 RDB 和 AOF 兩種持久化方案。

在介紹 RDB 和 AOF 方案時，不僅介紹它的作用及操作方法，同時介紹持久化實作的一些原理細節及需要注意的問題。最後，介紹在實際使用中，持久化方案的選擇，以及經常遇到的問題等。

下面分别從以下幾個方面講解：

Redis 高可用概述
Redis 持久化概述
RDB 持久化
AOF 持久化
方案選擇與常見問題
總結

在介紹 Redis 高可用之前，先說明一下在 Redis 的語境中高可用的含義。在 Web 伺服器中，高可用是指伺服器可以正常通路的時間，衡量的标準是在多長時間内可以提供正常服務（99.9%、99.99%、99.999% 等等）。

但是在 Redis 語境中，高可用的含義似乎要寬泛一些，除了保證提供正常服務(如主從分離、快速容災技術)，還需要考慮資料容量的擴充、資料安全不會丢失等。

在 Redis 中，實作高可用的技術主要包括持久化、複制、哨兵和叢集，下面分别說明它們的作用，以及解決了什麼樣的問題：

持久化：持久化是最簡單的高可用方法(有時甚至不被歸為高可用的手段)，主要作用是資料備份，即将資料存儲在硬碟，保證資料不會因程序退出而丢失。
複制：複制是高可用 Redis 的基礎，哨兵和叢集都是在複制基礎上實作高可用的。複制主要實作了資料的多機備份，以及對于讀操作的負載均衡和簡單的故障恢複。

缺陷：故障恢複無法自動化，寫操作無法負載均衡，存儲能力受到單機的限制。

哨兵：在複制的基礎上，哨兵實作了自動化的故障恢複。

缺陷：寫操作無法負載均衡；存儲能力受到單機的限制。

叢集：通過叢集，Redis 解決了寫操作無法負載均衡，以及存儲能力受到單機限制的問題，實作了較為完善的高可用方案。

持久化的功能：Redis 是記憶體資料庫，資料都是存儲在記憶體中。

為了避免程序退出導緻資料的永久丢失，需要定期将 Redis 中的資料以某種形式(資料或指令)從記憶體儲存到硬碟；當下次 Redis 重新開機時，利用持久化檔案實作資料恢複。

除此之外，為了進行災難備份，可以将持久化檔案拷貝到一個遠端位置。

Redis 持久化分為 RDB 持久化和 AOF 持久化：

前者将目前資料儲存到硬碟
後者則是将每次執行的寫指令儲存到硬碟（類似于 MySQL 的 binlog）

由于 AOF 持久化的實時性更好，即當程序意外退出時丢失的資料更少，是以 AOF 是目前主流的持久化方式，不過 RDB 持久化仍然有其用武之地。

下面依次介紹 RDB 持久化和 AOF 持久化；由于 Redis 各個版本之間存在差異，如無特殊說明，以 Redis 3.0 為準。

RDB 持久化是将目前程序中的資料生成快照儲存到硬碟(是以也稱作快照持久化)，儲存的檔案字尾是 RDB；當 Redis 重新啟動時，可以讀取快照檔案恢複資料。

觸發條件

RDB 持久化的觸發分為手動觸發和自動觸發兩種：

手動觸發
自動觸發

手動觸發：save 指令和 bgsave 指令都可以生成 RDB 檔案。

save 指令會阻塞 Redis 伺服器程序，直到 RDB 檔案建立完畢為止，在 Redis 伺服器阻塞期間，伺服器不能處理任何指令請求。

而 bgsave 指令會建立一個子程序，由子程序來負責建立 RDB 檔案，父程序(即 Redis 主程序)則繼續處理請求。

此時伺服器執行日志如下：

bgsave 指令執行過程中，隻有 fork 子程序時會阻塞伺服器，而對于 save 指令，整個過程都會阻塞伺服器。

是以 save 已基本被廢棄，線上環境要杜絕 save 的使用；後文中也将隻介紹 bgsave 指令。

此外，在自動觸發 RDB 持久化時，Redis 也會選擇 bgsave 而不是 save 來進行持久化；下面介紹自動觸發 RDB 持久化的條件。

自動觸發：最常見的情況是在配置檔案中通過 save m n，指定當 m 秒内發生 n 次變化時，會觸發 bgsave。

例如，檢視 Redis 的預設配置檔案(Linux 下為 Redis 根目錄下的 redis.conf)，可以看到如下配置資訊：

其中 save 900 1 的含義是：當時間到 900 秒時，如果 Redis 資料發生了至少 1 次變化，則執行 bgsave。

save 300 10 和 save 60 10000 同理，當三個 save 條件滿足任意一個時，都會引起 bgsave 的調用。

save m n 的實作原理：Redis 的 save m n，是通過 serverCron 函數、dirty 計數器和 lastsave 時間戳來實作的。

serverCron 是 Redis 伺服器的周期性操作函數，預設每隔 100ms 執行一次；該函數對伺服器的狀态進行維護，其中一項工作就是檢查 save m n 配置的條件是否滿足，如果滿足就執行 bgsave。

dirty 計數器是 Redis 伺服器維持的一個狀态，記錄了上一次執行 bgsave/save 指令後，伺服器狀态進行了多少次修改(包括增删改)；而當 save/bgsave 執行完成後，會将 dirty 重新置為 0。

例如，如果 Redis 執行了 set mykey helloworld，則 dirty 值會 +1；如果執行了 sadd myset v1 v2 v3，則 dirty 值會 +3；注意 dirty 記錄的是伺服器進行了多少次修改，而不是用戶端執行了多少修改資料的指令。

lastsave 時間戳也是 Redis 伺服器維持的一個狀态，記錄的是上一次成功執行 save/bgsave 的時間。

save m n 的原理如下：每隔 100ms，執行 serverCron 函數；在 serverCron 函數中，周遊 save m n 配置的儲存條件，隻要有一個條件滿足，就進行 bgsave。

對于每一個 save m n 條件，隻有下面兩條同時滿足時才算滿足：

目前時間-lastsave > m
dirty >= n

save m n 執行日志：下圖是 save m n 觸發 bgsave 執行時，伺服器列印日志的情況。

除了 save m n 以外，還有一些其他情況會觸發 bgsave：

在主從複制場景下，如果從節點執行全量複制操作，則主節點會執行 bgsave 指令，并将 RDB 檔案發送給從節點。
執行 shutdown 指令時，自動執行 RDB 持久化，如下圖所示：

執行流程

前面介紹了觸發 bgsave 的條件，下面将說明 bgsave 指令的執行流程，如下圖所示：

圖檔中的 5 個步驟所進行的操作如下：

Redis 父程序首先判斷：目前是否在執行 save 或 bgsave/bgrewriteaof（後面會詳細介紹該指令）的子程序，如果在執行則 bgsave 指令直接傳回。

bgsave/bgrewriteaof 的子程序不能同時執行，主要是基于性能方面的考慮：兩個并發的子程序同時執行大量的磁盤寫操作，可能引起嚴重的性能問題。

父程序執行 fork 操作建立子程序，這個過程中父程序是阻塞的，Redis 不能執行來自用戶端的任何指令。
父程序 fork 後，bgsave 指令傳回”Background saving started”資訊并不再阻塞父程序，并可以響應其他指令。
子程序建立 RDB 檔案，根據父程序記憶體快照生成臨時快照檔案，完成後對原有檔案進行原子替換。
子程序發送信号給父程序表示完成，父程序更新統計資訊。

RDB 檔案

RDB 檔案是經過壓縮的二進制檔案，下面介紹關于 RDB 檔案的一些細節。

存儲路徑

RDB 檔案的存儲路徑既可以在啟動前配置，也可以通過指令動态設定。

配置：dir 配置指定目錄，dbfilename 指定檔案名。預設是 Redis 根目錄下的 dump.rdb 檔案。

動态設定：Redis 啟動後也可以動态修改 RDB 存儲路徑，在磁盤損害或空間不足時非常有用；執行指令為 config set dir {newdir}和 config set dbfilename {newFileName}。

如下所示(Windows 環境)：

RDB 檔案格式

RDB 檔案格式如下圖所示：

其中各個字段的含義說明如下：

REDIS：常量，儲存着“REDIS”5 個字元。
db_version：RDB 檔案的版本号，注意不是 Redis 的版本号。
SELECTDB 0 pairs：表示一個完整的資料庫(0 号資料庫)，同理 SELECTDB 3 pairs 表示完整的 3 号資料庫。

隻有當資料庫中有鍵值對時，RDB 檔案中才會有該資料庫的資訊(上圖所示的 Redis 中隻有 0 号和 3 号資料庫有鍵值對)；如果 Redis 中所有的資料庫都沒有鍵值對，則這一部分直接省略。

其中：SELECTDB 是一個常量，代表後面跟着的是資料庫号碼；0 和 3 是資料庫号碼；pairs 則存儲了具體的鍵值對資訊，包括 key、value 值，及其資料類型、内部編碼、過期時間、壓縮資訊等等。

EOF：常量，标志 RDB 檔案正文内容結束。
check_sum：前面所有内容的校驗和；Redis 在載入 RBD 檔案時，會計算前面的校驗和并與 check_sum 值比較，判斷檔案是否損壞。

壓縮

Redis 預設采用 LZF 算法對 RDB 檔案進行壓縮。雖然壓縮耗時，但是可以大大減小 RDB 檔案的體積，是以壓縮預設開啟；可以通過指令關閉：

需要注意的是，RDB 檔案的壓縮并不是針對整個檔案進行的，而是對資料庫中的字元串進行的，且隻有在字元串達到一定長度(20 位元組)時才會進行。

啟動時加載

RDB 檔案的載入工作是在伺服器啟動時自動執行的，并沒有專門的指令。但是由于 AOF 的優先級更高，是以當 AOF 開啟時，Redis 會優先載入 AOF 檔案來恢複資料。

隻有當 AOF 關閉時，才會在 Redis 伺服器啟動時檢測 RDB 檔案，并自動載入。伺服器載入 RDB 檔案期間處于阻塞狀态，直到載入完成為止。

Redis 啟動日志中可以看到自動載入的執行：

Redis 載入 RDB 檔案時，會對 RDB 檔案進行校驗，如果檔案損壞，則日志中會列印錯誤，Redis 啟動失敗。

RDB 常用配置總結

下面是 RDB 常用的配置項，以及預設值，前面介紹過的這裡不再詳細介紹：

save m n：bgsave 自動觸發的條件；如果沒有 save m n 配置，相當于自動的 RDB 持久化關閉，不過此時仍可以通過其他方式觸發。
stop-writes-on-bgsave-error yes：當 bgsave 出現錯誤時，Redis 是否停止執行寫指令；設定為 yes，則當硬碟出現問題時，可以及時發現，避免資料的大量丢失。

設定為 no，則 Redis 無視 bgsave 的錯誤繼續執行寫指令，當對 Redis 伺服器的系統(尤其是硬碟)使用了監控時，該選項考慮設定為 no。

rdbcompression yes：是否開啟 RDB 檔案壓縮。
rdbchecksum yes：是否開啟 RDB 檔案的校驗，在寫入檔案和讀取檔案時都起作用；關閉 checksum 在寫入檔案和啟動檔案時大約能帶來 10% 的性能提升，但是資料損壞時無法發現。
dbfilename dump.rdb：RDB 檔案名。
dir ./：RDB 檔案和 AOF 檔案所在目錄。

RDB 持久化是将程序資料寫入檔案，而 AOF 持久化(即 Append Only File 持久化)，則是将 Redis 執行的每次寫指令記錄到單獨的日志檔案中（有點像 MySQL 的 binlog），當 Redis 重新開機時再次執行 AOF 檔案中的指令來恢複資料。

與 RDB 相比，AOF 的實時性更好，是以已成為主流的持久化方案。

開啟 AOF

Redis 伺服器預設開啟 RDB，關閉 AOF；要開啟 AOF，需要在配置檔案中配置：appendonly yes。

由于需要記錄 Redis 的每條寫指令，是以 AOF 不需要觸發，下面介紹 AOF 的執行流程。

AOF 的執行流程包括：

指令追加(append)：将 Redis 的寫指令追加到緩沖區 aof_buf。
檔案寫入(write)和檔案同步(sync)：根據不同的同步政策将 aof_buf 中的内容同步到硬碟。
檔案重寫(rewrite)：定期重寫 AOF 檔案，達到壓縮的目的。

指令追加(append)

Redis 先将寫指令追加到緩沖區，而不是直接寫入檔案，主要是為了避免每次有寫指令都直接寫入硬碟，導緻硬碟 IO 成為 Redis 負載的瓶頸。

指令追加的格式是 Redis 指令請求的協定格式，它是一種純文字格式，具有相容性好、可讀性強、容易處理、操作簡單避免二次開銷等優點，具體格式略。

在 AOF 檔案中，除了用于指定資料庫的 select 指令（如 select 0 為選中 0 号資料庫）是由 Redis 添加的，其他都是用戶端發送來的寫指令。

檔案寫入(write)和檔案同步(sync)

Redis 提供了多種 AOF 緩存區的同步檔案政策，政策涉及到作業系統的 write 函數和 fsync 函數，說明如下：

為了提高檔案寫入效率，在現代作業系統中，當使用者調用 write 函數将資料寫入檔案時，作業系統通常會将資料暫存到一個記憶體緩沖區裡，當緩沖區被填滿或超過了指定時限後，才真正将緩沖區的資料寫入到硬碟裡。

這樣的操作雖然提高了效率，但也帶來了安全問題：如果計算機停機，記憶體緩沖區中的資料會丢失。

是以系統同時提供了 fsync、fdatasync 等同步函數，可以強制作業系統立刻将緩沖區中的資料寫入到硬碟裡，進而確定資料的安全性。

AOF 緩存區的同步檔案政策由參數 appendfsync 控制，各個值的含義如下：

always：指令寫入 aof_buf 後立即調用系統 fsync 操作同步到 AOF 檔案，fsync 完成後線程傳回。

這種情況下，每次有寫指令都要同步到 AOF 檔案，硬碟 IO 成為性能瓶頸，Redis 隻能支援大約幾百 TPS 寫入，嚴重降低了 Redis 的性能。

即便是使用固态硬碟（SSD），每秒大約也隻能處理幾萬個指令，而且會大大降低 SSD 的壽命。

no：指令寫入 aof_buf 後調用系統 write 操作，不對 AOF 檔案做 fsync 同步；同步由作業系統負責，通常同步周期為 30 秒。

這種情況下，檔案同步的時間不可控，且緩沖區中堆積的資料會很多，資料安全性無法保證。

everysec：指令寫入 aof_buf 後調用系統 write 操作，write 完成後線程傳回；fsync 同步檔案操作由專門的線程每秒調用一次。

everysec 是前述兩種政策的折中，是性能和資料安全性的平衡，是以是 Redis 的預設配置，也是我們推薦的配置。

檔案重寫(rewrite)

随着時間流逝，Redis 伺服器執行的寫指令越來越多，AOF 檔案也會越來越大；過大的 AOF 檔案不僅會影響伺服器的正常運作，也會導緻資料恢複需要的時間過長。

檔案重寫是指定期重寫 AOF 檔案，減小 AOF 檔案的體積。需要注意的是，AOF 重寫是把 Redis 程序内的資料轉化為寫指令，同步到新的 AOF 檔案；不會對舊的 AOF 檔案進行任何讀取、寫入操作！

關于檔案重寫需要注意的另一點是：對于 AOF 持久化來說，檔案重寫雖然是強烈推薦的，但并不是必須的。即使沒有檔案重寫，資料也可以被持久化并在 Redis 啟動的時候導入。

是以在一些實作中，會關閉自動的檔案重寫，然後通過定時任務在每天的某一時刻定時執行。

檔案重寫之是以能夠壓縮 AOF 檔案，原因在于：

過期的資料不再寫入檔案。
無效的指令不再寫入檔案：如有些資料被重複設值(set mykey v1，set mykey v2)、有些資料被删除了(sadd myset v1，del myset)等等。
多條指令可以合并為一個：如 sadd myset v1，sadd myset v2，sadd myset v3 可以合并為 sadd myset v1 v2 v3。

不過為了防止單條指令過大造成用戶端緩沖區溢出，對于 list、set、hash、zset 類型的 key，并不一定隻使用一條指令。

而是以某個常量為界将指令拆分為多條。這個常量在 redis.h/REDIS_AOF_REWRITE_ITEMS_PER_CMD 中定義，不可更改，3.0 版本中值是 64。

通過上述内容可以看出，由于重寫後 AOF 執行的指令減少了，檔案重寫既可以減少檔案占用的空間，也可以加快恢複速度。

檔案重寫的觸發

檔案重寫的觸發，分為手動觸發和自動觸發：

手動觸發，直接調用 bgrewriteaof 指令，該指令的執行與 bgsave 有些類似：都是 fork 子程序進行具體的工作，且都隻有在 fork 時阻塞。

自動觸發，根據 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 參數，以及 aof_current_size 和 aof_base_size 狀态确定觸發時機：

auto-aof-rewrite-min-size：執行 AOF 重寫時，檔案的最小體積，預設值為 64MB。
auto-aof-rewrite-percentage：執行 AOF 重寫時，目前 AOF 大小(即 aof_current_size)和上一次重寫時 AOF 大小(aof_base_size)的比值。

其中，參數可以通過 config get 指令檢視：

狀态可以通過 info persistence 檢視：

隻有當 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 兩個參數同時滿足時，才會自動觸發 AOF 重寫，即 bgrewriteaof 操作。

自動觸發 bgrewriteaof 時，可以看到伺服器日志如下：

檔案重寫的流程

檔案重寫流程如下圖所示：

關于檔案重寫的流程，有兩點需要特别注意：

重寫由父程序 fork 子程序進行。
重寫期間 Redis 執行的寫指令，需要追加到新的 AOF 檔案中，為此 Redis 引入了 aof_rewrite_buf 緩存。

對照上圖，檔案重寫的流程如下：

1)：Redis 父程序首先判斷目前是否存在正在執行 bgsave/bgrewriteaof 的子程序，如果存在則 bgrewriteaof 指令直接傳回；如果存在 bgsave 指令則等 bgsave 執行完成後再執行，這個主要是基于性能方面的考慮。
2)：父程序執行 fork 操作建立子程序，這個過程中父程序是阻塞的。
3.1)：父程序 fork 後，bgrewriteaof 指令傳回“Background append only file rewrite started”資訊并不再阻塞父程序，并可以響應其他指令。

Redis 的所有寫指令依然寫入 AOF 緩沖區，并根據 appendfsync 政策同步到硬碟，保證原有 AOF 機制的正确。

3.2)：由于 fork 操作使用寫時複制技術，子程序隻能共享 fork 操作時的記憶體資料。

由于父程序依然在響應指令，是以 Redis 使用 AOF 重寫緩沖區(圖中的 aof_rewrite_buf)儲存這部分資料，防止新 AOF 檔案生成期間丢失這部分資料。

也就是說，bgrewriteaof 執行期間，Redis 的寫指令同時追加到 aof_buf 和 aof_rewirte_buf 兩個緩沖區。

4)：子程序根據記憶體快照，按照指令合并規則寫入到新的 AOF 檔案。
5.1)：子程序寫完新的 AOF 檔案後，向父程序發信号，父程序更新統計資訊，具體可以通過 info persistence 檢視。
5.2)：父程序把 AOF 重寫緩沖區的資料寫入到新的 AOF 檔案，這樣就保證了新 AOF 檔案所儲存的資料庫狀态和伺服器目前狀态一緻。
5.3)：使用新的 AOF 檔案替換老檔案，完成 AOF 重寫。

前面提到過，當 AOF 開啟時，Redis 啟動時會優先載入 AOF 檔案來恢複資料；隻有當 AOF 關閉時，才會載入 RDB 檔案恢複資料。

當 AOF 開啟，且 AOF 檔案存在時，Redis 啟動日志：

當 AOF 開啟，但 AOF 檔案不存在時，即使 RDB 檔案存在也不會加載(更早的一些版本可能會加載，但 3.0 不會)，Redis 啟動日志如下：

檔案校驗

與載入 RDB 檔案類似，Redis 載入 AOF 檔案時，會對 AOF 檔案進行校驗，如果檔案損壞，則日志中會列印錯誤，Redis 啟動失敗。

但如果是 AOF 檔案結尾不完整(機器突然當機等容易導緻檔案尾部不完整)，且 aof-load-truncated 參數開啟，則日志中會輸出警告，Redis 忽略掉 AOF 檔案的尾部，啟動成功。

aof-load-truncated 參數預設是開啟的：

僞用戶端

因為 Redis 的指令隻能在用戶端上下文中執行，而載入 AOF 檔案時指令是直接從檔案中讀取的，并不是由用戶端發送。

是以 Redis 伺服器在載入 AOF 檔案之前，會建立一個沒有網絡連接配接的用戶端，之後用它來執行 AOF 檔案中的指令，指令執行的效果與帶網絡連接配接的用戶端完全一樣。

AOF 常用配置總結

下面是 AOF 常用的配置項，以及預設值：

appendonly no：是否開啟 AOF。
appendfilename "appendonly.aof"：AOF 檔案名。
appendfsync everysec：fsync 持久化政策。
no-appendfsync-on-rewrite no：AOF 重寫期間是否禁止 fsync；如果開啟該選項，可以減輕檔案重寫時 CPU 和硬碟的負載（尤其是硬碟），但是可能會丢失 AOF 重寫期間的資料；需要在負載和安全性之間進行平衡。
auto-aof-rewrite-percentage 100：檔案重寫觸發條件之一。
auto-aof-rewrite-min-size 64mb：檔案重寫觸發送出之一。
aof-load-truncated yes：如果 AOF 檔案結尾損壞，Redis 啟動時是否仍載入 AOF 檔案。

前面介紹了 RDB 和 AOF 兩種持久化方案的細節，下面介紹 RDB 和 AOF 的特點、如何選擇持久化方案，以及在持久化過程中常遇到的問題等。

RDB 和 AOF 的優缺點

RDB 和 AOF 各有優缺點：

優點：RDB 檔案緊湊，體積小，網絡傳輸快，适合全量複制；恢複速度比 AOF 快很多。當然，與 AOF 相比，RDB 最重要的優點之一是對性能的影響相對較小。

缺點：RDB 檔案的緻命缺點在于其資料快照的持久化方式決定了必然做不到實時持久化，而在資料越來越重要的今天，資料的大量丢失很多時候是無法接受的，是以 AOF 持久化成為主流。

此外，RDB 檔案需要滿足特定格式，相容性差（如老版本的 Redis 不相容新版本的 RDB 檔案）。

與 RDB 持久化相對應，AOF 的優點在于支援秒級持久化、相容性好，缺點是檔案大、恢複速度慢、對性能影響大。

持久化政策選擇

在介紹持久化政策之前，首先要明白無論是 RDB 還是 AOF，持久化的開啟都是要付出性能方面代價的：

對于 RDB 持久化，一方面是 bgsave 在進行 fork 操作時 Redis 主程序會阻塞，另一方面，子程序向硬碟寫資料也會帶來 IO 壓力。
對于 AOF 持久化，向硬碟寫資料的頻率大大提高(everysec 政策下為秒級)，IO 壓力更大，甚至可能造成 AOF 追加阻塞問題（後面會詳細介紹這種阻塞）。

此外，AOF 檔案的重寫與 RDB 的 bgsave 類似，會有 fork 時的阻塞和子程序的 IO 壓力問題。

相對來說，由于 AOF 向硬碟中寫資料的頻率更高，是以對 Redis 主程序性能的影響會更大。

在實際生産環境中，根據資料量、應用對資料的安全要求、預算限制等不同情況，會有各種各樣的持久化政策。

如完全不使用任何持久化、使用 RDB 或 AOF 的一種，或同時開啟 RDB 和 AOF 持久化等。

此外，持久化的選擇必須與 Redis 的主從政策一起考慮，因為主從複制與持久化同樣具有資料備份的功能，而且主機 master 和從機 slave 可以獨立的選擇持久化方案。

下面分場景來讨論持久化政策的選擇，讨論也隻是作為參考，實際方案可能更複雜更具多樣性：

如果 Redis 中的資料完全丢棄也沒有關系（如 Redis 完全用作 DB 層資料的 Cache），那麼無論是單機，還是主從架構，都可以不進行任何持久化。
在單機環境下（對于個人開發者，這種情況可能比較常見），如果可以接受十幾分鐘或更多的資料丢失，選擇 RDB 對 Redis 的性能更加有利；如果隻能接受秒級别的資料丢失，應該選擇 AOF。
但在多數情況下，我們都會配置主從環境，slave 的存在既可以實作資料的熱備，也可以進行讀寫分離分擔 Redis 讀請求，以及在 master 宕掉後繼續提供服務。

在這種情況下，一種可行的做法是：

master：完全關閉持久化（包括 RDB 和 AOF），這樣可以讓 master 的性能達到最好。
slave：關閉 RDB，開啟 AOF（如果對資料安全要求不高，開啟 RDB 關閉 AOF 也可以），并定時對持久化檔案進行備份（如備份到其他檔案夾，并标記好備份的時間）。

然後關閉 AOF 的自動重寫，然後添加定時任務，在每天 Redis 閑時（如淩晨 12 點）調用 bgrewriteaof。

這裡需要解釋一下，為什麼開啟了主從複制，可以實作資料的熱備份，還需要設定持久化呢？

因為在一些特殊情況下，主從複制仍然不足以保證資料的安全，例如：

master 和 slave 程序同時停止：考慮這樣一種場景，如果 master 和 slave 在同一棟大樓或同一個機房，則一次停電事故就可能導緻 master 和 slave 機器同時關機，Redis 程序停止；如果沒有持久化，則面臨的是資料的完全丢失。
master誤重新開機：考慮這樣一種場景，master 服務因為故障宕掉了，如果系統中有自動拉起機制（即檢測到服務停止後重新開機該服務）将 master 自動重新開機，由于沒有持久化檔案，那麼 master 重新開機後資料是空的，slave 同步資料也變成了空的；如果 master 和 slave 都沒有持久化，同樣會面臨資料的完全丢失。

需要注意的是，即便是使用了哨兵(關于哨兵後面會有文章介紹)進行自動的主從切換，也有可能在哨兵輪詢到 master 之前，便被自動拉起機制重新開機了。是以，應盡量避免“自動拉起機制”和“不做持久化”同時出現。

異地災備：上述讨論的幾種持久化政策，針對的都是一般的系統故障，如程序異常退出、當機、斷電等，這些故障不會損壞硬碟。

但是對于一些可能導緻硬碟損壞的災難情況，如火災地震，就需要進行異地災備。

例如對于單機的情形，可以定時将 RDB 檔案或重寫後的 AOF 檔案，通過 scp 拷貝到遠端機器，如阿裡雲、AWS 等。

對于主從的情形，可以定時在 master 上執行 bgsave，然後将 RDB 檔案拷貝到遠端機器，或者在 slave 上執行 bgrewriteaof 重寫 AOF 檔案後，将 AOF 檔案拷貝到遠端機器上。

一般來說，由于 RDB 檔案檔案小、恢複快，是以災難恢複常用 RDB 檔案；異地備份的頻率根據資料安全性的需要及其他條件來确定，但最好不要低于一天一次。

fork 阻塞：CPU 的阻塞

在 Redis 的實踐中，衆多因素限制了 Redis 單機的記憶體不能過大，例如：

當面對請求的暴增，需要從庫擴容時，Redis 記憶體過大會導緻擴容時間太長。
當主機當機時，切換主機後需要挂載從庫，Redis 記憶體過大導緻挂載速度過慢。
持久化過程中的 fork 操作。

首先說明一下 fork 操作：父程序通過 fork 操作可以建立子程序；子程序建立後，父子程序共享代碼段，不共享程序的資料空間，但是子程序會獲得父程序的資料空間的副本。

在作業系統 fork 的實際實作中，基本都采用了寫時複制技術，即在父/子程序試圖修改資料空間之前，父子程序實際上共享資料空間。

但是當父/子程序的任何一個試圖修改資料空間時，作業系統會為修改的那一部分(記憶體的一頁)制作一個副本。

雖然 fork 時，子程序不會複制父程序的資料空間，但是會複制記憶體頁表（頁表相當于記憶體的索引、目錄）；父程序的資料空間越大，記憶體頁表越大，fork 時複制耗時也會越多。

在 Redis 中，無論是 RDB 持久化的 bgsave，還是 AOF 重寫的 bgrewriteaof，都需要 fork 出子程序來進行操作。

如果 Redis 記憶體過大，會導緻 fork 操作時複制記憶體頁表耗時過多；而 Redis 主程序在進行 fork 時，是完全阻塞的，也就意味着無法響應用戶端的請求，會造成請求延遲過大。

對于不同的硬體、不同的作業系統，fork 操作的耗時會有所差别，一般來說，如果 Redis 單機記憶體達到了 10GB，fork 時耗時可能會達到百毫秒級别（如果使用 Xen 虛拟機，這個耗時可能達到秒級别）。

是以，一般來說 Redis 單機記憶體一般要限制在 10GB 以内；不過這個資料并不是絕對的，可以通過觀察線上環境 fork 的耗時來進行調整。

觀察的方法如下：執行指令 info stats，檢視 latest_fork_usec 的值，機關為微秒。

為了減輕 fork 操作帶來的阻塞問題，除了控制 Redis 單機記憶體的大小以外，還可以适度放寬 AOF 重寫的觸發條件、選用實體機或高效支援 fork 操作的虛拟化技術等，例如使用 Vmware 或 KVM 虛拟機，不要使用 Xen 虛拟機。

AOF 追加阻塞：硬碟的阻塞

前面提到過，在 AOF 中，如果 AOF 緩沖區的檔案同步政策為 everysec，則在主線程中，指令寫入 aof_buf 後調用系統 write 操作，write 完成後主線程傳回。

fsync 同步檔案操作由專門的檔案同步線程每秒調用一次。這種做法的問題在于，如果硬碟負載過高，那麼 fsync 操作可能會超過 1s。

如果 Redis 主線程持續高速向 aof_buf 寫入指令，硬碟的負載可能會越來越大，IO 資源消耗更快；如果此時 Redis 程序異常退出，丢失的資料也會越來越多，可能遠超過 1s。

為此，Redis 的處理政策是這樣的：主線程每次進行 AOF 會對比上次 fsync 成功的時間；如果距上次不到 2s，主線程直接傳回；如果超過 2s，則主線程阻塞直到 fsync 同步完成。

是以，如果系統硬碟負載過大導緻 fsync 速度太慢，會導緻 Redis 主線程的阻塞；此外，使用 everysec 配置，AOF 最多可能丢失 2s 的資料，而不是 1s。

AOF 追加阻塞問題定位的方法：

監控 info Persistence 中的 aof_delayed_fsync：當 AOF 追加阻塞發生時（即主線程等待 fsync 而阻塞），該名額累加。
AOF 阻塞時的 Redis 日志：Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.
如果 AOF 追加阻塞頻繁發生，說明系統的硬碟負載太大，可以考慮更換 IO 速度更快的硬碟，或者通過 IO 監控分析工具對系統的 IO 負載進行分析，如 iostat（系統級 io）、iotop（io 版的 top）、pidstat 等。

info 指令與持久化

前面提到了一些通過 info 指令檢視持久化相關狀态的方法，下面來總結一下。

info Persistence

執行結果如下：

其中比較重要的包括：

rdb_last_bgsave_status：上次 bgsave 執行結果，可以用于發現 bgsave 錯誤。
rdb_last_bgsave_time_sec：上次 bgsave 執行時間（機關是 s），可以用于發現 bgsave 是否耗時過長。
aof_enabled：AOF 是否開啟。
aof_last_rewrite_time_sec：上次檔案重寫執行時間（機關是 s），可以用于發現檔案重寫是否耗時過長。
aof_last_bgrewrite_status：上次 bgrewrite 執行結果，可以用于發現 bgrewrite 錯誤。
aof_buffer_length 和 aof_rewrite_buffer_length：AOF 緩存區大小和 AOF 重寫緩沖區大小。
aof_delayed_fsync：AOF 追加阻塞情況的統計。

info stats

其中與持久化關系較大的是：latest_fork_usec，代表上次 fork 耗時，可以參見前面的讨論。

本文主要内容可以總結如下：

持久化在 Redis 高可用中的作用：資料備份，與主從複制相比強調的是由記憶體到硬碟的備份。
RDB 持久化：将資料快照備份到硬碟；介紹了其觸發條件（包括手動出發和自動觸發）、執行流程、RDB 檔案等，特别需要注意的是檔案儲存操作由 fork 出的子程序來進行。
AOF 持久化：将執行的寫指令備份到硬碟（類似于 MySQL 的 binlog），介紹了其開啟方法、執行流程等，特别需要注意的是檔案同步政策的選擇（everysec）、檔案重寫的流程。
一些現實的問題：包括如何選擇持久化政策，以及需要注意的 fork 阻塞、AOF 追加阻塞等。

作者：程式設計迷思

出處：https://www.cnblogs.com/kismetv/p/9137897.html

好消息！第十屆 GOPS（GOPS2018全球運維大會·上海站）即将火爆來襲！！

GOPS 2018 全球運維大會 · 上海站

目前拟定的部分精彩議題包括：

還有另外50個大咖演講在路上。您可掃碼或點選閱讀原文，以了解更多。

掃碼即可了解更多或立即報名

更多詳情，也可點選閱讀原文

閱讀原文