目錄
大部分源自：https://www.jianshu.com/p/9c7f0f786c5b
redis持久化的意義：
redis持久化的意義主要在於故障恢復，比如你部署一個redis，作爲緩存有可能裏邊有一些比較重要的數據，如果沒有持久化的時候，redis遇到災難性故障的時候就會丟失所有的數據。
多以持久化是必不可少的。
AOF持久化機制對每條寫入命令作爲日誌，以append-only模式寫入一個日誌文件中，在redis重啓的時候，可以通過AOF寫入的指令來重新構建整個數據集。
通過RDB和AOF都可以將redis內存中的數據持久化到硬盤上，然後可以將數據備份到雲服務器上。
如果redis掛了可以從雲服務器上的備份文件copy到指定位置然後重啓redis，redis就會自動持久化文件中的數據，去恢復內存中的數據。
如果同時使用RDB和AOF兩種持久化機制，那麼redis重啓的時候，會使用AOF來構建數據，因爲AOF的數據更加完整。
快照(snapshotting，RDB)![]()
Redis可以通過創建快照來獲得存儲在內存裏面的數據在某個時間點上的副本。Redis創建快照之後，可以對快照進行備份，可以將快照複製到其他服務器從而創建具有相同數據的服務器副本(Redis主從結構，主要用來提高Redis性 能)，還可以將快照留在原地以便重啓服務器的時候使用。 RDB持久化機制對redis中的數據執行週期性的持久化。
快照持久化是Redis默認採用的持久化方式，在redis.conf配置文件中默認有此下配置:
save 900 1 #在900秒(15分鐘)之後，如果至少有1個key發生變化，Redis就會自動觸發BGSAVE命令創建快照。
save 300 10 #在300秒(5分鐘)之後，如果至少有10個key發生變化，Redis就會自動觸發BGSAVE命令創建快照。
save 60 10000 #在60秒(1分鐘)之後，如果至少有10000個key發生變化，Redis就會自動觸發BGSAVE命令創建快照。
當滿足條件時,redis需要執行RDB的時候服務器會執行以下操作：
1.redis調用系統的fork()函數創建一個子進程
2.子進程將數據集寫入一個臨時的RDB文件
3.當子進程完成對臨時的RDB文件的寫入時，redis用新的RDB文件來替換原來舊的RDB文件，並將舊的RDB文件刪除
redis在進行快照的過程中不會對RDB文件進行修改，只有快照結束後纔會將舊快照替換成新快照，也就是說任何時候RDB都是完整的
RDB優點：
（1）RDB會生成多個數據文件，每個數據文件都代表了某一個時刻中redis的數據，這種多個數據文件的方式，非常適合做冷備。
（2）RDB對redis對外提供讀寫服務的時候，影像非常小，因爲redis 主進程只需要fork一個子進程出來，讓子進程對磁盤io來進行rdb持久化
(3).RDB 在恢復大數據集時的速度比 AOF 的恢復速度要快。
RDB缺點
（1）如果redis要故障時要儘可能少的丟失數據，RDB沒有AOF好，例如1:00進行的快照，在1:10又要進行快照的時候宕機了，這個時候就會丟失10分鐘的數據。
（2）RDB每次fork出子進程來執行RDB快照生成文件時，如果文件特別大，可能會導致客戶端提供服務暫停數毫秒或者幾秒
只追加文件(append-only file,AOF)
與快照持久化相比，AOF持久化 的實時性更好，因此已成爲主流的持久化方案。默認情況下Redis沒有開啓 AOF(append only file)方式的持久化，可以通過appendonly參數開啓:
appendonly yes
在Redis的配置文件中存在三種不同的 AOF 持久化方式，它們分別是:
appendfsync always #每次有數據修改發生時都會寫入AOF文件,這樣會嚴重降低Redis的速度
appendfsync everysec #每秒鐘同步一次，顯示地將多個寫命令同步到硬盤
appendfsync no #讓操作系統決定何時進行同步
爲了兼顧數據和寫入性能，用戶可以考慮 appendfsync everysec選項 ，讓Redis每秒同步一次AOF文件，Redis性能 幾乎沒受到任何影響。而且這樣即使出現系統崩潰，用戶最多隻會丟失一秒之內產生的數據。當硬盤忙於執行寫入操 作的時候，Redis還會優雅的放慢自己的速度以便適應硬盤的最大寫入速度。
redis中的數據是有一定限量的，不可能說redis中的數據無限增長，進而導致AOF文件無限增長。
內存大小是一定的，等到了一定大小redis 會採用淘汰策略lru,自動將內存中的數據清除掉
AOF是存放每條寫命令的，所以會不斷的增大，當大到一定程度時，AOF會做rewrite操作,rewrite操作就是基於當時redis的數據重新構造一個小的AOF文件，然後將大的AOF文件刪除。
AOF的優點：
（1）AOF可以更好的保護數據不丟失，一般AOF會以每隔1秒，通過後臺的一個線程去執行一次fsync操作，如果redis進程掛掉，最多丟失1秒的數據。
（2）AOF以appen-only的模式寫入，所以沒有任何磁盤尋址的開銷，寫入性能非常高。
（3）AOF日誌文件的命令通過非常可讀的方式進行記錄，這個非常適合做災難性的誤刪除緊急恢復，如果某人不小心用flushall命令清空了所有數據，只要這個時候還沒有執行rewrite，那麼就可以將日誌文件中的flushall刪除，進行恢復。
AOF的缺點
（1）對於同一份文件AOF文件比RDB數據快照要大。
（2）AOF開啓後支持寫的QPS會比RDB支持的寫的QPS低，因爲AOF一般會配置成每秒fsync操作，每秒的fsync操作還是很高的
（3）數據恢復比較慢，不適合做冷備。
RDB和AOF到底如何選擇
（1）不要僅僅使用RDB這樣會丟失很多數據。
（2）也不要僅僅使用AOF，因爲這一會有兩個問題，第一通過AOF做冷備沒有RDB做冷備恢復的速度快；第二RDB每次簡單粗暴生成數據快照，更加健壯。
（3）綜合AOF和RDB兩種持久化方式，用AOF來保證數據不丟失，作爲恢復數據的第一選擇；用RDB來做不同程度的冷備，在AOF文件都丟失或損壞不可用的時候，可以使用RDB進行快速的數據恢復。
Redis 4.0 對於持久化機制的優化
Redis 4.0 開始支持 RDB 和 AOF 的混合持久化(默認關閉，可以通過配置項 aof-use-rdb-preamble 開啓)。
如果把混合持久化打開，AOF 重寫的時候就直接把 RDB 的內容寫到 AOF 文件開頭。
好處：結合 RDB 和 AOF 的優點, 快速加載同時避免丟失過多的數據。
缺點：AOF 裏面的 RDB 部分是壓縮格式不再是 AOF 格式，可讀性較差。
補充內容:AOF 重寫
AOF重寫可以產生一個新的AOF文件，這個新的AOF文件和原有的AOF文件所保存的數據庫狀態一樣，但體積更小。
AOF重寫是一個有歧義的名字，該功能是通過讀取數據庫中的鍵值對來實現的，程序無須對現有AOF文件進行任伺讀 入、分析或者寫入操作。
在執行 BGREWRITEAOF 命令時，Redis 服務器會維護一個 AOF 重寫緩衝區，該緩衝區會在子進程創建新AOF文件期 間，記錄服務器執行的所有寫命令。當子進程完成創建新AOF文件的工作之後，服務器會將重寫緩衝區中的所有內容 追加到新AOF文件的末尾，使得新舊兩個AOF文件所保存的數據庫狀態一致。最後，服務器用新的AOF文件替換舊的 AOF文件，以此來完成AOF文件重寫操作