Redis是一個No-SQ緩存數據庫，數據保存在內存中，由於讀寫頻繁，或在出現宕機等等異常情況，數據往往會丟失。不用擔心，Redis給我們提供了持久化的機制，分別是RDB(Redis DataBase)和AOF(Append Only File)。
一、持久化流程
（1）客戶端向服務端發送寫操作(數據在客戶端的內存中)。
（2）數據庫服務端接收到寫請求的數據(數據在服務端的內存中)。
（3）服務端調用write這個系統調用，將數據往磁盤上寫(數據在系統內存的緩衝區中)。
（4）操作系統將緩衝區中的數據轉移到磁盤控制器上(數據在磁盤緩存中)。
（5）磁盤控制器將數據寫到磁盤的物理介質中(數據真正落到磁盤上)。
以上是正常的保存流程，但是在大多數情況下，我們的機器會出現不同的故障，這裏劃分了兩種情況：
（1）Redis數據庫發生故障，只要在上面的第三步執行完畢，那麼就可以持久化保存，剩下的兩步由操作系統替我們完成。
（2）操作系統發生故障，必須上面5步都完成纔可以。
二、RDB機制
RDB其實就是把數據以快照的形式保存在磁盤上。什麼是快照呢，你可以理解成把當前時刻的數據拍成一張照片保存下來。
RDB持久化是指在指定的時間間隔內，將內存中的數據集以快照的形式，寫入磁盤。也是默認的持久化方式，這種方式是就是將內存中數據以快照的方式寫入到二進制文件中,默認的文件名爲dump.rdb。在redis.conf文件中，有RDB和AOF兩種持久化機制的各種配置。
既然RDB機制是通過把某個時刻的所有數據生成一個快照來保存，那麼就應該有一種觸發機制，是實現這個過程。對於RDB來說，提供了三種機制：save、bgsave、自動觸發。
1、Save觸發方式
該命令會阻塞當前Redis，然後執行Save命令，期間無法使用Redis其他命令，RDB過程完成之後自動釋放，這種方式侷限性比較大，基本不會使用到，他會嚴重影響其他客戶端使用。如下圖：
2、Bgsave觸發方式
執行該命令時，Redis會異步執行快照操作，同時也能處理客戶端發送過來的請求。如下圖：
具體流程：Redis進程執行fork操作，創建子進程，RDB持久化（快照）操作交由子進程負責，完成後自動結束。在fork階段，Redis會發生阻塞，一般時間很短，（下篇文章會講到Redis fork優化），正常都採取這種方式進行RDB持久化。
Save和Bgsave對比：
3、自動觸發
通過配置redis.conf文件，進行觸發設置，以下主要配置.
（1）save：配置觸發 Redis的 RDB 持久化條件，主要是多少時間段內，KEY的變化，然後觸發保存操作 。“save x y”,x 爲時間，y爲key值變化次數。以下三Redis默認配置：
save 900 1 、save 300 10、save 60 10000
（2）stop-writes-on-bgsave-error：設置了對Redis服務器和持久性的監視，默認值爲yes。將即使磁盤或在權限出現故障，也Redis也照常工作。
（3）rdbcompression：對於存儲到磁盤中的快照，可以設置是否進行壓縮存儲。默認值是yes，
（4）rdbchecksum：默認值是yes。在存儲快照後，我們還可以讓redis使用CRC64算法來進行數據校驗，但是這樣做會增加大約10%的性能消耗。
（5）dbfilename: 設置快照的文件名，默認是 dump.rdb
（6）dir:設置快照文件的存放路徑。
4、RDB 的優勢和劣勢
①、優勢
（1）RDB文件緊湊，全量備份，非常適合用於進行備份和災難恢復。
（2）生成RDB文件的時候，redis主進程會fork()一個子進程來處理所有保存工作，主進程不需要進行任何磁盤IO操作。
（3）RDB 在恢復大數據集時的速度比 AOF 的恢復速度要快。
②、劣勢
RDB快照是一次全量備份，存儲的是內存數據的二進制序列化形式，存儲上非常緊湊。當進行快照持久化時，會開啓一個子進程專門負責快照持久化，子進程會擁有父進程的內存數據，父進程修改內存子進程不會反應出來，所以在快照持久化期間修改的數據不會被保存，可能丟失數據。
三、AOF機制
全量備份總是耗時的，Redis提供一種更加高效的方式AOF，工作機制很簡單，redis會將每一個收到的寫命令都通過write函數追加到AOF文件中，通常在redis-server同級目錄下。
1、持久化原理
每當有一個寫命令過來時，就直接保存在我們的AOF文件中，如下圖：
2、文件重寫原理
AOF明顯的會帶來一個問題：持久化文件會越來越大，該怎麼辦呢？Redis提供一個 bgrewriteaof 命令，將內存中的數據保存到臨時文件中，同時fork會創建一個新線程進行文件重寫。注意：重寫時，並不會讀取舊的AOF文件，而是將整個內存中數據重寫到新的一個AOF文件中，類似於RDB快照。
3、AOF三種觸發機制
（1）每次修改同步always：同步持久化 每次發生數據變更會被立即記錄到磁盤 性能較差但數據完整性比較好
（2）每秒同步everysec：異步操作，每秒記錄 如果一秒內宕機，有數據丟失
（3）不同no：從不同步
4、優點
（1）AOF可以更好的保護數據不丟失，一般AOF會每隔1秒，通過一個後臺線程執行一次fsync操作，最多丟失1秒鐘的數據。
（2）AOF日誌文件沒有任何磁盤尋址的開銷，寫入性能非常高，文件不容易破損。
（3）AOF日誌文件即使過大的時候，出現後臺重寫操作，也不會影響客戶端的讀寫。
（4）AOF日誌文件的命令通過可讀的方式進行記錄，這個特性適合做災難性的誤刪除的緊急恢復。比如誤操作用flushall命令清空了所有數據，只要這個時候後臺rewrite還沒有發生，那麼就可以立即拷貝AOF文件，將最後一條flushall命令給刪了，然後再將該AOF文件放回去，就可以通過恢復機制，自動恢復所有數據。
5、缺點
（1）對於同一份數據來說，AOF日誌文件通常比RDB數據快照文件更大。
四、RDB和AOF對比
通過以上介紹，相信都有一定的瞭解，根據實際需求進行選擇，如下圖：
