原創：享學課堂講師
轉載請聲明出處！
RDB
RDB 是 Redis 默認的持久化方案。在指定的時間間隔內，執行指定次數的寫操作，則會將內存中的數據寫入到磁盤中。即在指定目錄下生成一個dump.rdb文件。Redis重啓會通過加載dump.rdb文件恢復數據。
找到配置文件，在配置redis.conf文件裏面找下如下的配置
save 60 1000
這個配置指的是,每隔60s，如果有超過1000個key發生了變更，那麼就生成一個新的dump.rdb文件，就是當前redis內存中完整的數據快照，這個操作也被稱之爲snapshotting快照。
當然你也可以手動調用save或者bgsave命令，同步或異步執行rdb快照生成，同時save可以設置多個，就是多個snapshotting檢查點，每到一個檢查點，就會去check一下，是否有指定的key數量發生了變更，如果有，就生成一個新的dump.rdb文件。
上面畫了個簡單的圖，描繪的是RDB持久化機制的工作流程，具體來看可以有如下幾個步驟：
（1）redis根據配置自己嘗試去生成rdb快照文件
（2）fork一個子進程出來
（3）子進程嘗試將數據dump到臨時的rdb快照文件中
（4）完成rdb快照文件的生成之後就替換之前的舊的快照文件dump.rdb，每次生成一個新的快照，都會覆蓋之前的老快照
AOF
AOF ：Redis 默認不開啓。它的出現是爲了彌補RDB的不足（數據的不一致性），所以它採用日誌的形式來記錄每個寫操作，並追加到文件中。Redis重啓的會根據日誌文件的內容將寫指令從前到後執行一次以完成數據的恢復工作。
找到配置文件後，你需要修改的第一個配置爲：
appendonly yes
以打開AOF持久化機制，在生產環境裏面，一般來說AOF都是要打開的，除非你說隨便丟個幾分鐘的數據也無所謂。
打開AOF持久化機制之後，redis每次接收到一條寫命令，就會寫入日誌文件中，當然是先寫入oscache的，然後每隔一定時間再fsync一下磁盤文件。
除開appendonly的這個配置項，關於AOF還有一個非常有意思的配置:
appendfsync everysec
這個appendfsync 默認值是everysec，除開這個以外，總共有3個取值的可能：
always: 每次寫入一條數據，立即將這個數據對應的寫日誌fsync到磁盤上去，性能非常非常差，吞吐量很低; 確保說redis裏的數據一條都不丟，那就只能這樣了。
everysec:每秒將oscache中的數據fsync到磁盤，這個最常用的，生產環境一般都這麼配置，性能很高，QPS還是可以上萬的。
no:僅僅redis負責將數據寫入oscache就撒手不管了，然後後面os自己會時不時有自己的策略將數據刷入磁盤，不可控了。
可見默認值就是最好的選項了
（1）redisfork一個子進程。
（2）子進程基於當前內存中的數據，構建日誌，開始往一個新的臨時的AOF文件中寫入日誌。
（3）redis主進程，接收到client新的寫操作之後，在內存中寫入日誌，同時新的日誌也繼續寫入舊的AOF文件。
（4）子進程寫完新的日誌文件之後，redis主進程將內存中的新日誌再次追加到新的AOF文件中。
（5）用新的日誌文件替換掉舊的日誌文件。
- Redis 默認開啓RDB持久化方式，在指定的時間間隔內，執行指定次數的寫操作，則將內存中的數據寫入到磁盤中。
- RDB 持久化適合大規模的數據恢復但它的數據一致性和完整性較差。
- Redis 需要手動開啓AOF持久化方式，默認是每秒將寫操作日誌追加到AOF文件中。
- AOF 的數據完整性比RDB高，但記錄內容多了，會影響數據恢復的效率。
- Redis 針對AOF文件大的問題，提供重寫的瘦身機制。
- 若只打算用Redis做緩存，可以關閉持久化。
- 若打算使用Redis的持久化。建議RDB和AOF都開啓。其實RDB更適合做數據的備份，留一後手。AOF出問題了，還有RDB。
如果喜歡本文，可以關注我們的官方賬號，第一時間獲取資訊。
你的關注是對我們更新最大的動力哦~