持久化選項

• 快照持久化：獲得存儲在內存里面的數據在某個時間點上的副本。

• AOF持久化（只追加文件append-only file）：會在執行命令時，將被執行的寫命令寫到硬盤里。

兩種方案既可同時使用，也可單獨使用，或都不使用，具體結合數據及應用決定。

# 快照持久化選項
#save 900 1
#save 300 10
save 60 10000

stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename "dump.rdb"
dir "/home/ycl/install/redis"

# AOF持久化選項
appendonly no
appendfilename "appendonly.aof"

# appendfsync always
appendfsync everysec
# appendfsync no

no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
dir "/home/ycl/install/redis" #共享選項：決定快照文件和AOF文件保存位置

快照持久化

在新的快照文件創建完畢之前，Redis、系統或硬件三者之中任意一個崩潰，那么Redis將丟失最近一次快照后的所有數據。

創建快照方法：

1. 客戶端向Redis發BGSAVE命令（除windows平臺）。Redis調用fork創建一個子進程，然后子進程負責將快照寫入硬盤，父進程繼續處理命令請求。

2. 客戶端向Redis發SAVE命令。SAVE命令在快照創建完成前不再響應任何其他命令。SAVE命令不常用，除非沒有足夠內存執行BGSAVE命令。

3. 配置SAVE選項。如save 60 10000，從Redis最近一次創建快照之后開始算起，“60s之內有10000次寫入”。

4. SHUTDOWN或其它標準TERM信號會使Redis執行一個SAVE命令，阻塞所有客戶端，不再執行客戶端發送任何命令，SAVE結束關閉服務器。

5. 一個Redis向另一個Redis發送SYNC命令進行復制操作，若服務器沒執行BGSAVE則主服務器進行BGSAVE。

使用場景

1. 個人開發：盡可能降低快照帶來的資源消耗。如 save 900 1

2. 日志聚合計算：將日志的處理進度記錄到Redis里，程序在系統崩潰后根據進度記錄繼續執行之前未完成工作。

3. 大數據：幾G的數據量Redis創建子進程將數據保存到硬盤沒問題，但Redis所占內存增大時，BGSAVE創建子進程耗時也會增加。若Redis占幾十G且剩余內存不多時，或Redis跑在虛擬機上時，BGSAVE將使系統長時間停頓、引發系統大量使用虛擬內存，使Redis性能降低。為此，需關閉自動保存。但手動BGSAVE也會有同樣問題，只是人為控制了出現停頓的時間而已。另一方面，SAVE因不用創建子進程，沒有進程間爭奪資源等創建快照更快一些。

AOF持久化

建議使用appendfsync everysec選項，AOF文件每秒同步一次，可以將丟失數據時間窗口降低至1s，性能和不使用任何持久化性能相差無幾。問題是AOF文件體積會不斷增大——①占用過多硬盤空間 ②還原數據慢

BGREWRITEAOF

該命令會移除AOF文件中冗余命令來重寫AOF文件。

具體過程如下

1、redis 調用 fork ，現在有父子兩個進程

2、子進程根據內存中的數據庫快照，往臨時文件中寫入重建數據庫狀態的命令

3、父進程繼續處理 client 請求，除了把寫命令寫入到原來的 aof 文件中。同時把收到的寫命令緩存起來。這樣就能保證如果子進程重寫失敗的話并不會出問題。

4、當子進程把快照內容寫入已命令方式寫到臨時文件中后，子進程發信號通知父進程。然后父進程把緩存的寫命令也寫入到臨時文件。

5、現在父進程可以使用臨時文件替換老的 aof 文件，并重命名，后面收到的寫命令也開始往新的 aof 文件中追加。