redis是一個內存數據庫，數據保存在內存中，但是我們都知道內存的數據變化是很快的，也容易發生丟失。幸好Redis還為我們提供了持久化的機制，分別是RDB(Redis DataBase)和AOF(Append Only File)。
在這裡假設你已經瞭解了redis的基礎語法，某字母網站都有很好的教程，可以去看。基本使用的文章就不寫了，都是一些常用的命令。
下面針對這兩種方式來介紹一下。由淺入深。
一、持久化流程
既然redis的數據可以保存在磁盤上，那麼這個流程是什麼樣的呢？
要有下面五個過程：
（1）客戶端向服務端發送寫操作(數據在客戶端的內存中)。
（2）數據庫服務端接收到寫請求的數據(數據在服務端的內存中)。
（3）服務端調用write這個系統調用，將數據往磁盤上寫(數據在系統內存的緩衝區中)。
（4）操作系統將緩衝區中的數據轉移到磁盤控制器上(數據在磁盤緩存中)。
（5）磁盤控制器將數據寫到磁盤的物理介質中(數據真正落到磁盤上)。
這5個過程是在理想條件下一個正常的保存流程，但是在大多數情況下，我們的機器等等都會有各種各樣的故障，這裡劃分了兩種情況：
（1）Redis數據庫發生故障，只要在上面的第三步執行完畢，那麼就可以持久化保存，剩下的兩步由操作系統替我們完成。
（2）操作系統發生故障，必須上面5步都完成才可以。
在這裡只考慮了保存的過程可能發生的故障，其實保存的數據也有可能發生損壞，需要一定的恢復機制，不過在這裡就不再延伸了。現在主要考慮的是redis如何來實現上面5個保存磁盤的步驟。它提供了兩種策略機制，也就是RDB和AOF。
二、RDB機制
RDB其實就是把數據以快照的形式保存在磁盤上。什麼是快照呢，你可以理解成把當前時刻的數據拍成一張照片保存下來。
RDB持久化是指在指定的時間間隔內將內存中的數據集快照寫入磁盤。也是默認的持久化方式，這種方式是就是將內存中數據以快照的方式寫入到二進制文件中,默認的文件名為dump.rdb。
在我們安裝了redis之後，所有的配置都是在redis.conf文件中，裡面保存了RDB和AOF兩種持久化機制的各種配置。
既然RDB機制是通過把某個時刻的所有數據生成一個快照來保存，那麼就應該有一種觸發機制，是實現這個過程。對於RDB來說，提供了三種機制：save、bgsave、自動化。我們分別來看一下
1、save觸發方式
該命令會阻塞當前Redis服務器，執行save命令期間，Redis不能處理其他命令，直到RDB過程完成為止。具體流程如下：
執行完成時候如果存在老的RDB文件，就把新的替代掉舊的。我們的客戶端可能都是幾萬或者是幾十萬，這種方式顯然不可取。
2、bgsave觸發方式
執行該命令時，Redis會在後臺異步進行快照操作，快照同時還可以響應客戶端請求。
具體操作是Redis進程執行fork操作創建子進程，RDB持久化過程由子進程負責，完成後自動結束。阻塞只發生在fork階段，一般時間很短。基本上 Redis 內部所有的RDB操作都是採用 bgsave 命令。
3、自動觸發
自動觸發是由我們的配置文件來完成的。在redis.conf配置文件中，裡面有如下配置，我們可以去設置：
①save：這裡是用來配置觸發 Redis的 RDB 持久化條件，也就是什麼時候將內存中的數據保存到硬盤。比如“save m n”。表示m秒內數據集存在n次修改時，自動觸發bgsave。
默認如下配置：
#表示900 秒內如果至少有 1 個 key 的值變化，則保存save 900 1#表示300 秒內如果至少有 10 個 key 的值變化，則保存save 300 10#表示60 秒內如果至少有 10000 個 key 的值變化，則保存save 60 10000
不需要持久化，那麼你可以註釋掉所有的 save 行來停用保存功能。
②stop-writes-on-bgsave-error ：默認值為yes。當啟用了RDB且最後一次後臺保存數據失敗，Redis是否停止接收數據。這會讓用戶意識到數據沒有正確持久化到磁盤上，否則沒有人會注意到災難（disaster）發生了。如果Redis重啟了，那麼又可以重新開始接收數據了
③rdbcompression ；默認值是yes。對於存儲到磁盤中的快照，可以設置是否進行壓縮存儲。
④rdbchecksum ：默認值是yes。在存儲快照後，我們還可以讓redis使用CRC64算法來進行數據校驗，但是這樣做會增加大約10%的性能消耗，如果希望獲取到最大的性能提升，可以關閉此功能。
⑤dbfilename ：設置快照的文件名，默認是 dump.rdb
⑥dir：設置快照文件的存放路徑，這個配置項一定是個目錄，而不能是文件名。
我們可以修改這些配置來實現我們想要的效果。因為第三種方式是配置的。
4、RDB 的優勢和劣勢
①、優勢
（1）RDB文件緊湊，全量備份，非常適合用於進行備份和災難恢復。
（2）生成RDB文件的時候，redis主進程會fork()一個子進程來處理所有保存工作，主進程不需要進行任何磁盤IO操作。
（3）RDB 在恢復大數據集時的速度比 AOF 的恢復速度要快。
②、劣勢
RDB快照是一次全量備份，存儲的是內存數據的二進制序列化形式，存儲上非常緊湊。當進行快照持久化時，會開啟一個子進程專門負責快照持久化，子進程會擁有父進程的內存數據，父進程修改內存子進程不會反應出來，所以在快照持久化期間修改的數據不會被保存，可能丟失數據。
三、AOF機制
全量備份總是耗時的，有時候我們提供一種更加高效的方式AOF，工作機制很簡單，redis會將每一個收到的寫命令都通過write函數追加到文件中。通俗的理解就是日誌記錄。
1、持久化原理
每當有一個寫命令過來時，就直接保存在我們的AOF文件中。
2、文件重寫原理
AOF的方式也同時帶來了另一個問題。持久化文件會變的越來越大。為了壓縮aof的持久化文件。redis提供了bgrewriteaof命令。將內存中的數據以命令的方式保存到臨時文件中，同時會fork出一條新進程來將文件重寫。
重寫aof文件的操作，並沒有讀取舊的aof文件，而是將整個內存中的數據庫內容用命令的方式重寫了一個新的aof文件，這點和快照有點類似。
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數據快照文件更大
（2）AOF開啟後，支持的寫QPS會比RDB支持的寫QPS低，因為AOF一般會配置成每秒fsync一次日誌文件，當然，每秒一次fsync，性能也還是很高的
（3）以前AOF發生過bug，就是通過AOF記錄的日誌，進行數據恢復的時候，沒有恢復一模一樣的數據出來。
四、RDB和AOF到底該如何選擇
選擇的話，兩者加一起才更好。因為兩個持久化機制你明白了，剩下的就是看自己的需求了，需求不同選擇的也不一定，但是通常都是結合使用。
對比了這幾個特性，剩下的就是看自己了。
