Redis 持久化詳解

• http://www.redis.cn/topics/pe...

持久化

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/langxS...