作為記憶體資料庫，Redis 依然提供了持久化機制，其主要目的有兩個：
- 安全：保證程式崩潰後資料不會丟失
- 備份：方便資料遷移與快速恢復
Redis 同時提供兩種持久化機制：
- RDB 快照：資料庫在某個時間點的完整狀態，其儲存內容為鍵值對
- AOF 日誌：包含所有改變資料庫狀態的操作，其儲存內容為命令
RDB 快照
生成 RDB 快照的方式有兩種：
- 服務程式定期生成
- 手動執行 SAVE 或 BGSAVE 命令
定期生成
使用者可以通過設定儲存點save point，控制 RDB 快照的自動生成：
save 900 1 # 最近 15 分鐘內，至少有 1 個 key 發生過變更
save 300 10 # 最近 5 分鐘內，至少有 10 個 key 發生過變更
save 60 10000 # 最近 1 分鐘內，至少有 10000 個 key 發生過變更
struct saveparam {
time_t seconds; // 秒數
int changes; // 變更數
};
struct redisServer {
// ...
struct saveparam *saveparams; /* RDB 儲存點陣列 */
int saveparamslen; /* 儲存點數量 */
long long dirty; /* 上一次執行快照後的變更數 */
time_t lastsave; /* 上一次執行快照的 UNIX 時間戳 */
}
+---------------+
| redisServer |
+---------------+ +---------------+---------------+---------------+
| saveparams | -> | saveparams[0] | saveparams[1] | saveparams[2] |
+---------------+ +---------------+---------------+---------------+
| saveparamslen | | seconds | seconds | seconds |
| 3 | | 900 | 300 | 60 |
+---------------+ +---------------+---------------+---------------+
| dirty | | changes | changes | changes |
| 120 | | 1 | 10 | 10000 |
+---------------+ +---------------+---------------+---------------+
| lastsave |
| 1378270800 |
+---------------+
自動儲存的過程：
- 每執行一個資料庫修改命令，計數器 dirty 就會記錄該記錄導致的變更數量
- Redis 的定時任務
serverCron會週期性地檢查是否滿足儲存點條件：
int serverCron(struct aeEventLoop *eventLoop, long long id, void *clientData) {
// ...
for (j = 0; j < server.saveparamslen; j++) {
struct saveparam *sp = server.saveparams+j;
if (server.dirty >= sp->changes && // 檢查變更數是否足夠
server.unixtime-server.lastsave > sp->seconds) // 檢查最近一次快照時間
{
// 如果當前狀態滿足儲存點設定，列印日誌並開始執行 BGSAVE
serverLog(LL_NOTICE,"%d changes in %d seconds. Saving...", sp->changes, (int)sp->seconds);
// ...
// 執行 BGSAVE
rdbSaveBackground(server.rdb_filename,rsiptr);
break;
}
}
}
手動備份
為了避免在流量高峰期發生效能抖動，在生產環境中往往會關閉 Redis 的自動生成快照的功能。為了保證資料安全，此時運維會使用定時指令碼的方式，在系統空閒時執行 BGSAVE 命令備份 Redis 資料。
int rdbSaveBackground(char *filename, rdbSaveInfo *rsi) {
// ...
if ((childpid = redisFork(CHILD_TYPE_RDB)) == 0) { // 產生子程式
/* 子程式負責生成 RDB 快照 */
int retval = rdbSave(filename,rsi);
// ...
} else {
/* 主程式不阻塞直接返回 */
serverLog(LL_NOTICE,"Background saving started by pid %d",childpid);
updateDictResizePolicy(); // 如果子程式正生成快照，禁止 dict 進行 rehash 操作
// ...
return C_OK;
}
}
RDB 檔案由子程式生成的，作業系統寫時複製 copy-on-write 的優化特性，決定了父子程式間的記憶體在邏輯上是獨立的。
因此主程式所產生的任何修改操作都不會被包含在 RDB 檔案中，間接保證了 RDB 所記錄狀態的一致性。
RDB 檔案
RDB 快照是一個二進位制檔案，其格式大致如下：
# 有 n 個資料庫的 RDB 檔案
+-------+------------+-------+-----+-------+-----+-----------+
| REDIS | db_version | db[0] | ... | db[n] | EOF | check_sum |
+-------+------------+-------+-----+-------+-----+-----------+
# 每個資料庫包含任意長度的鍵值對
+-------+ +----------+---+------------+-----+------------+
| db[0] | => | SELECTDB | 0 | kv_pair[0] | ... | kv_pair[n] |
+-------+ +----------+---+------------+-----+------------+
# 鍵值對，常量 TYPE 指示了 value 的編碼型別
+---------+ +------+-----+-------+
| kv_pair | => | TYPE | key | value |
+---------+ +------+-----+-------+
# 帶過期時間的鍵值對，常量 EXPIRETIME_MS 緊接著一個 8 位元組的時間戳
+------------------+ +---------------+--------------+------+-----+-------+
| kv_pair_with_ttl | => | EXPIRETIME_MS | ms_timestamp | TYPE | key | value |
+------------------+ +---------------+--------------+------+-----+-------+
RDB 快照儲存了資料庫在某個時間點的完整狀態，且格式緊湊，十分適合作為資料備份：
- 方便通過網路傳輸到異地機櫃，實現多機房容災
- 通過使用 RESTORE 命令載入 RDB 快照，可以實現資料初始化或者緊急回滾
AOF 日誌
生成 RDB 快照的過程比較耗時，無法頻繁執行 BGSAVE。但如果狀態變更長時間不落盤，一旦程式崩潰，將會丟失大量未持久化的資料。
為了避免全量備份的開銷，Redis 支援以增量更新的方式，將狀態變更持久化到 AOF 日誌中，減少對磁碟 I/O 的壓力。
由於 AOF 日誌落盤是由主執行緒完成的，因此落盤策略會明顯影響到 Redis 的效能。下列配置項可用於控制這一行為：
appendonly no # 是否開啟 AOF
# 落盤策略
# always：每次發生變更會立即落盤
# everysec：每秒落盤一次
# no：由作業系統決定落盤時機
appendfsync everysec
struct redisServer {
// ...
int aof_enabled; /* AOF 開關 */
int aof_state; /* AOF 狀態（開啟、關閉、等待重寫）*/
int aof_fsync; /* fsync 策略 */
sds aof_buf; /* AOF 緩衝 */
time_t aof_flush_postponed_start; /* AOF 延遲重新整理 UNIX 時間戳 */
}
追加命令
每當成功執行完一條命令，會通過 processCommand -> call -> propagate -> feedAppendOnlyFile 這條呼叫鏈，將命令寫入 AOF 快取：
void feedAppendOnlyFile(struct redisCommand *cmd, int dictid, robj **argv, int argc) {
// 將命令追加到緩衝末尾，在向客戶端返回結果前將其寫入 AOF 檔案中
if (server.aof_state == AOF_ON)
server.aof_buf = sdscatlen(server.aof_buf,buf,sdslen(buf));
// 如果有子執行緒正在執行 AOF 重寫，期間會將新增的修改記錄入一個新的 AOF 日誌
if (server.aof_child_pid != -1)
aofRewriteBufferAppend((unsigned char*)buf,sdslen(buf));
}
寫入檔案
在 serverCron 事件迴圈結束前，會呼叫 flushAppendOnlyFile 將緩衝中的命令寫入到 AOF 日誌檔案中：
int serverCron(struct aeEventLoop *eventLoop, long long id, void *clientData) {
// ...
// AOF延遲重新整理：每個 cron 迴圈都執行執行一次 fsync
if (server.aof_flush_postponed_start) flushAppendOnlyFile(0);
}
void flushAppendOnlyFile(int force) {
ssize_t nwritten;
int sync_in_progress = 0;
if (sdslen(server.aof_buf) == 0) { // 緩衝為空直接返回
// ...
return;
}
// 將命令寫入 AOF 檔案，此時尚未落盤
nwritten = aofWrite(server.aof_fd,server.aof_buf,sdslen(server.aof_buf));
server.aof_flush_postponed_start = 0; // 寫入完成，重置延遲重新整理時間戳，避免再次觸發
// ...
if (server.aof_fsync == AOF_FSYNC_ALWAYS) {
// 落盤策略為 always，則立即執行 fsync
redis_fsync(server.aof_fd);
server.aof_fsync_offset = server.aof_current_size;
server.aof_last_fsync = server.unixtime;
} else if ((server.aof_fsync == AOF_FSYNC_EVERYSEC &&
server.unixtime > server.aof_last_fsync)) {
// 落盤策略為 everysec，則 fsync 交由後臺程式非同步完成
if (!sync_in_progress) {
aof_background_fsync(server.aof_fd);
server.aof_fsync_offset = server.aof_current_size;
}
server.aof_last_fsync = server.unixtime;
}
}
值得注意的是，如果寫入 AOF 檔案過程中發生錯誤，且落盤策略為 always，此時 Redis 程式會直接退出。
日誌重寫
在不斷接收寫命令的過程中，AOF 檔案會越來越大，這將導致以下問題：
- 檔案系統對檔案大小有限制，無法儲存過大的檔案
- 故障恢復時，需要逐個執行 AOF 日誌的命令，如果日誌檔案太大，將導致整個過程會非常緩慢
導致該問題的一個重要原因就是存在冗餘命令：
# 執行命令
127.0.0.1:6379> INCR counter
(integer) 1
127.0.0.1:6379> INCR counter
(integer) 2
127.0.0.1:6379> INCR counter
(integer) 3
# 對應的 AOF 日誌
*2\r\n$6\r\nSELECT\r\n$1\r\n0\r\n
*2\r\n$4\r\nINCR\r\n$7\r\ncounter\r\n
*2\r\n$4\r\nINCR\r\n$7\r\ncounter\r\n
*2\r\n$4\r\nINCR\r\n$7\r\ncounter\r\n
Redis 提供了重寫機制rewrite，能夠大幅縮減不必要的冗餘命令：
# 重寫日誌，並輸出到一個新的檔案中
127.0.0.1:6379> BGREWRITEAOF
# 重寫後的 AOF 日誌將 3 個 INCR 命令轉化為 1 個 SET 命令
*2\r\n$6\r\nSELECT\r\n$1\r\n0\r\n
*3\r\n$3\r\nSET\r\n$7\r\ncounter\r\n$1\r\n3
除了手動執行 BGREWRITEAOF 命令之外，Redis 也支援自動觸發 AOF 重寫。下列配置項可用於控制這一行為：
# 重寫策略
no-appendfsync-on-rewrite no # 重寫 AOF 日誌時禁止落盤
auto-aof-rewrite-percentage 100 # 當增長百分比超過該值時，觸發 AOF 重寫
auto-aof-rewrite-min-size 64mb # 當日志檔案體積超過該值後，觸發 AOF 重寫
struct redisServer {
// ...
int aof_no_fsync_on_rewrite; /* 重寫 AOF 過程中禁止呼叫 fsync 落盤 */
int aof_rewrite_perc; /* 觸發 AOF 重寫的檔案增長百分比 */
off_t aof_rewrite_min_size; /* 觸發 AOF 重寫的最小檔案體積 */
int aof_rewrite_scheduled; /* 是否有重寫操作在等待 BGSAVE 完成 */
list *aof_rewrite_buf_blocks; /* AOF 重寫緩衝 */
}
Redis 的定時任務 serverCron 會週期性地檢查是否滿足重寫條件：
int serverCron(struct aeEventLoop *eventLoop, long long id, void *clientData) {
/*
延遲重寫：在伺服器執行 BGSAVE 命令期間，如果接收到 BGWRITEAOF 命令，會將其延遲到 BGSAVE 完成後再執行，避免相互爭搶磁碟資源 I/O
*/
if (!hasActiveChildProcess() && // 無執行後臺操作的子程式，意味著 BGSAVE 已經完成
server.aof_rewrite_scheduled) // 存在等待執行的 BGWRITEAOF 命令
{
rewriteAppendOnlyFileBackground();
}
// ...
if (server.aof_state == AOF_ON &&
server.aof_rewrite_perc &&
server.aof_current_size > server.aof_rewrite_min_size) // 檢查日誌體積是否達標
{
// 檢查日誌增量是否達標
long long base = server.aof_rewrite_base_size ?
server.aof_rewrite_base_size : 1;
long long growth = (server.aof_current_size*100/base) - 100;
if (growth >= server.aof_rewrite_perc) {
// 如果當前狀態滿足重寫條件，列印日誌並開始執行 BGREWRITEAOF
serverLog(LL_NOTICE,"Starting automatic rewriting of AOF on %lld%% growth",growth);
rewriteAppendOnlyFileBackground();
}
}
}
int rewriteAppendOnlyFileBackground(void) {
// ...
if ((childpid = redisFork(CHILD_TYPE_AOF)) == 0) {
/* 子程式負責重寫 AOF 日誌 */
char tmpfile[256];
if (rewriteAppendOnlyFile(tmpfile) == C_OK) {
// ...
}
} else {
/* 主程式不阻塞直接返回 */
serverLog(LL_NOTICE,
"Background append only file rewriting started by pid %d",childpid);
updateDictResizePolicy();
return C_OK;
}
}
重寫過程中，主執行緒仍然正常對外服務，資料庫狀態仍然會進行變更，但子程式重寫後的 AOF 不會包含這些變更。
因此，這些新增的命令會被同時追加到 AOF 緩衝 server.aof_buf 與 重寫緩衝 server.aof_rewrite_buf_blocks 中。當子程式重寫完成後，將 重寫緩衝 追加至重寫完成的 AOF 日誌中即可。
此外，為了避免與子程式的重寫過程爭搶磁碟I/O，可以通過 aof_no_fsync_on_rewrite 禁止主程式在重寫期間呼叫 fsync 落盤 AOF 日誌。
兩者比較
RDB 快照
優點：檔案結構緊湊，節省空間，易於傳輸，能夠快速恢復
缺點：生成快照的開銷只與資料庫大小相關，當資料庫較大時，生成快照耗時，無法頻繁進行該操作
AOF 日誌
優點：細粒度記錄對磁碟I/O壓力小，允許頻繁落盤，資料丟失的概率極低
缺點：恢復速度慢；記錄日誌開銷與更新頻率有關，頻繁更新會導致磁碟 I/O 壓力上升