Redis 持久化詳解

• http://www.redis.cn/topics/persistence.html

持久化

Redis 如同其他的存儲組件一樣，提供了兩類持久化方式：快照，和全量追加日誌。

RDB - 快照

在預設情況下， Redis 將資料庫快照保存在名字為dump.rdb的二進位文件中。
你可以對 Redis 進行設置， 讓它在“ N 秒內數據集至少有 M 個改動”這一條件被滿足時， 自動保存一次數據集。
你也可以通過調用 SAVE或者 BGSAVE ， 手動讓 Redis 進行數據集保存操作。
這種持久化方式被稱為快照 snapshotting.

• SAVE：暫停服務，寫dump.rdb，比如停止時執行
• BGSAVE ：通過fork系統調用創建子進程寫 dump.rdb

# 配置寫入策略（針對bgsave）：
save  900  1                      #（900秒內至少1個key被寫）
save  300  10                   #（300秒內至少10個key被寫）
save  60  10000              #（60秒內至少1000個key被寫）
# 如果不需要RDB,可以設置：
save ""
# 設置 rdb 文件名稱 和 存儲目錄
dbfilename     dump.rdb
dir   /var/lib/redis/6379

AOF - 只追加操作的文件（Append-only file，AOF）

快照功能並不是非常耐久（durable）： 如果 Redis 因為某些原因而造成故障停機， 那麼伺服器將丟失最近寫入、且仍未保存到快照中的那些數據。
從 1.1 版本開始， Redis 增加了一種完全耐久的持久化方式： AOF 持久化。

appendonly yes      #（開啟AOF）
appendfilename    "appendonly.aof" 

每當 Redis 執行一個改變數據集的命令時（比如 SET）， 這個命令就會被追加到 AOF 文件的末尾。
這樣的話， 當 Redis 重新啟時， 程式就可以通過重新執行 AOF 文件中的命令來達到重建數據集的目的。

fsync 同步刷盤策略

你可以配置 Redis 多久才將數據 fsync 到磁碟一次。有三種方式：

• 每次有新命令追加到 AOF 文件時就執行一次 fsync ：非常慢，也非常安全
• 每秒 fsync 一次：足夠快（和使用 RDB 持久化差不多），並且在故障時只會丟失 1 秒鐘的數據。
• 從不 fsync ：將數據交給操作系統來處理。更快，也更不安全的選擇。
• 推薦（並且也是預設）的措施為每秒 fsync 一次， 這種 fsync 策略可以兼顧速度和安全性。

# fsync同步刷盤策略
# appendfsync always   #（立刻同步刷盤，最慢，也最安全）
appendfsync everysec   #（每秒才觸發一次同步刷盤，推薦）
# appendfsync no        # （不採用同步刷盤，最快，相對不安全）

日誌重寫

因為 AOF 的運作方式是不斷地將命令追加到文件的末尾， 所以隨著寫入命令的不斷增加， AOF 文件的體積也會變得越來越大。
舉個例子， 如果你對一個計數器調用了 100 次 INCR ， 那麼僅僅是為了保存這個計數器的當前值， AOF 文件就需要使用 100 條記錄（entry）。
然而在實際上， 只使用一條 SET 命令已經足以保存計數器的當前值了， 其餘 99 條記錄實際上都是多餘的。

為了處理這種情況， Redis 支持一種有趣的特性： 可以在不打斷服務客戶端的情況下， 對 AOF 文件進行重建（rebuild）。
執行 BGREWRITEAOF 命令， Redis 將生成一個新的 AOF 文件， 這個文件包含重建當前數據集所需的最少命令。

# 配置：AOF文件每次增長指定大小的百分比後，就會觸發BGREWRITEAOF
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

從 Redis 4.0 開始，AOF重寫邏輯變動了：

• 老數據採用 RDB 的 fork寫入 aof文件的頭部
• 以後增量的命令追加到aof文件尾部
  這樣的方式，AOF是一個混合體，利用了RDB的快，利用了日誌的全量，使得 Redis 持久化更加安全和完善。

@SvenAugustus (https://my.oschina.net/langxSpirit)