redis的數據在運行期間都是保存在內存中，當服務器重啓時，redis服務器會從磁盤中加載之前已經持久化到磁盤中的數據。而且，redis服務器突然宕機，保存在內存中的數據就會丟失，顯得redis的持久化機制更爲重要。redis提供了兩種持久化機制。
第一種是RDB方式。
默認情況下，你沒有做任何配置的話，redis就是使用這種方式進行持久化。基本的原理就是將當前內存中的所有數據進行快照，然後寫入磁盤中。
打開reids安裝目錄下的redis.conf文件。dir屬性指定了持久化文件的位置，dbfilename屬性指定了持久化文件的名稱，默認叫dump.rdb。打開這個rdb文件看一眼，發現完全看不懂，因爲這是經過壓縮的二進制文件，這個文件記錄了內存中的所有的數據（快照那一刻的）。每 進行一次快照，就會用新的rdb文件代替舊的。下面說一下哪些情況下，redis會進行快照。
1. 還看redis.conf文件，有幾個save屬性。
save 900 1
save 300 10
save 60 10000默認是三行，第一行的意思是900秒內有1次寫的操作時就會快照一次；第二行的意思是，300秒內有10次寫的操作就會快照一次；第三行不說了。這三個條件是或的關係。如果你喜歡，可以再添加幾行，也可以全部刪掉他們。如果你全部刪掉的話，這種通過規定時間內檢測寫操作次數來進行快照的功能就丟掉了。
2. 執行save命令，這個命令可以手動告訴服務器快照一次，但這個是這個阻塞操作，在快照結束之前，其他線程是無法訪問服務器的，可以用bgsave命令代替save命令，這個命令可以在後臺快照。
3. 服務器正常關閉時。
第二種是AOF方式。
顯然，經過剛纔的介紹，大家肯定擔心，萬一redis還沒來得及快照，突然宕機了，那最後一次快照至宕機這段時間內的數據是不是就丟了。是的，確實就丟了。如果你覺得這個問題不可忍受的話，可以用AOF方式來解決這個問題。
AOF方式的原理是，每執行一次寫操作，redis就會向一個持久化文件中追加幾行命令來記錄這次寫操作。這樣，問題解決了，但是效率卻降低了。剛纔已經說過，AOF方式默認是不開啓的，需要修改配置文件，還是redis.conf文件，修改appendonly屬性爲yes就可以開啓AOF，AOF的持久化文件的路徑和名稱是通過dir和appendfilename指定的，默認名稱叫做appendonly.aof。
*2
$6
SELECT
$1
0
*3
$3
set
$1
a
$1
a
*2
$6
SELECT
$1
0
*3
$3
set
$14
dffkjdasdjflda
$67
dkjjfdkjdkafjs;ja;sfdjfdas;fdsa;fjdasj;fjas;dfdsajf;jdasjfdsjfijasd這個文件大概可以看明白，主要看set這個單詞就可以了。每個set代表一次寫操作。你可能會說，如果我反覆的設置同一個鍵的值，redis會追加幾條命令呢。答案是redis在追加時不做檢查，冗餘就冗餘吧。但是每當滿足一定條件時，redis就會去刪除這些冗餘的命令。你不能指望redis每次執行寫操作都要去刪除冗餘的命令，這樣效率太低了。我們可以通過設置下面兩個屬性，來控制redis什麼時候去刪除冗餘的命令，這裏不做過多介紹了。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb另外，如果你開啓了AOF方式的話，當服務器重啓時，就會從AOF的持久化文件中加載數，不會再找RDB的快照持久化文件了。
關於AOF方式持久化的兩個坑，大家看一下，不要再跳進去了。
第一個我給大家演示以下。
第一步，就使用默認的RDB方式，存入幾個鍵值對。然後正常關閉服務器。這時候，數據已經持久化到rdb文件中了。正常開啓服務器的化，這些數據可以正常加載回來。不信的話你可以試一下。
第二步，編輯redis.conf文件，開啓AOF方式。然後開啓服務器，你會發現剛纔存的數據都丟了。
這一點都不意外，我不解釋了。
第二個是，不要以爲開啓了AOF，數據就不會丟失了，這裏有一個緩存的概念。
當執行寫操作時，redis確實向磁盤發出了寫的命令。但是磁盤會將這些命令緩存起來，每隔一段時間才向磁盤同步一下數據。這樣，仍然存在數據丟失的風險。可以在redis.conf中設置一下。
appendfsync always
# appendfsync everysec
# appendfsync no第一個的意思是，不需要緩存，也就是redis要求操作系統馬上執行寫的操作；第二個是使用緩存，但是每秒鐘同步一下數據；第三個就是默認使用緩存。