來源：https://www.cnblogs.com/xingzc/p/5988080.html

　　Redis是一種面向“key-value”型別資料的分散式NoSQL資料庫系統，具有高效能、持久儲存、適應高併發應用場景等優勢。它雖然起步較晚，但發展卻十分迅速。 

近日，Redis的作者在部落格中寫到，他看到的所有針對Redis的討論中，對Redis持久化的誤解是最大的，於是他寫了一篇長文來對Redis的持久化進行了系統性的論述。

文章主要包含三個方面：Redis持久化是如何工作的、這一效能是否可靠以及和其它型別的資料庫比較。以下為文章內容： 

一、Redis持久化是如何工作的？

首先我們來看一下資料庫在進行寫操作時到底做了哪些事，主要有下面五個過程： 

• 客戶端向服務端傳送寫操作（資料在客戶端的記憶體中）。
• 資料庫服務端接收到寫請求的資料（資料在服務端的記憶體中）。
• 服務端呼叫write這個系統呼叫，將資料往磁碟上寫（資料在系統記憶體的緩衝區中）。
• 作業系統將緩衝區中的資料轉移到磁碟控制器上（資料在磁碟快取中）。
• 磁碟控制器將資料寫到磁碟的物理介質中（資料真正落到磁碟上）。

故障分析 

寫操作大致有上面5個流程，下面我們結合上面的5個流程看一下各種級別的故障： 

• 當資料庫系統故障時，這時候系統核心還是完好的。那麼此時只要我們執行完了第3步，那麼資料就是安全的，因為後續作業系統會來完成後面幾步，保證資料最終會落到磁碟上。
• 當系統斷電時，這時候上面5項中提到的所有快取都會失效，並且資料庫和作業系統都會停止工作。所以只有當資料在完成第5步後，才能保證在斷電後資料不丟失。

通過上面5步的瞭解，可能我們會希望搞清下面一些問題： 

• 資料庫多長時間呼叫一次write，將資料寫到核心緩衝區？
• 核心多長時間會將系統緩衝區中的資料寫到磁碟控制器？
• 磁碟控制器又在什麼時候把快取中的資料寫到物理介質上？

　　對於第一個問題，通常資料庫層面會進行全面控制。

　　而對第二個問題，作業系統有其預設的策略，但是我們也可以通過POSIX API提供的fsync系列命令強制作業系統將資料從核心區寫到磁碟控制器上。

　　對於第三個問題，好像資料庫已經無法觸及，但實際上，大多數情況下磁碟快取是被設定關閉的，或者是隻開啟為讀快取，也就是說寫操作不會進行快取，直接寫到磁碟。

　　建議的做法是僅僅當你的磁碟裝置有備用電池時才開啟寫快取。 

資料損壞 

　　所謂資料損壞，就是資料無法恢復，上面我們講的都是如何保證資料是確實寫到磁碟上去，但是寫到磁碟上可能並不意味著資料不會損壞。比如我們可能一次寫請求會進行兩次不同的寫操作，當意外發生時，可能會導致一次寫操作安全完成，但是另一次還沒有進行。如果資料庫的資料檔案結構組織不合理，可能就會導致資料完全不能恢復的狀況出現。 

這裡通常也有三種策略來組織資料，以防止資料檔案損壞到無法恢復的情況： 
 

• • 第一種是最粗糙的處理，就是不通過資料的組織形式保證資料的可恢復性。而是通過配置資料同步備份的方式，在資料檔案損壞後通過資料備份來進行恢復。實際上MongoDB在不開啟操作日誌，通過配置Replica Sets時就是這種情況。
  • 另一種是在上面基礎上新增一個操作日誌，每次操作時記一下操作的行為，這樣我們可以通過操作日誌來進行資料恢復。因為操作日誌是順序追加的方式寫的，所以不會出現操作日誌也無法恢復的情況。這也類似於MongoDB開啟了操作日誌的情況。
  • 更保險的做法是資料庫不進行舊資料的修改，只是以追加方式去完成寫操作，這樣資料本身就是一份日誌，這樣就永遠不會出現資料無法恢復的情況了。實際上CouchDB就是此做法的優秀範例。

二 、Redis提供了RDB持久化和AOF持久化

RDB機制的優勢和略施

　　RDB持久化是指在指定的時間間隔內將記憶體中的資料集快照寫入磁碟。

　　也是預設的持久化方式，這種方式是就是將記憶體中資料以快照的方式寫入到二進位制檔案中,預設的檔名為dump.rdb。

可以通過配置設定自動做快照持久化的方式。我們可以配置redis在n秒內如果超過m個key被修改就自動做快照，下面是預設的快照儲存配置

   save 900 1     #900秒內如果超過1個key被修改，則發起快照儲存
   save 300 10    #300秒內容如超過10個key被修改，則發起快照儲存
   save 60 10000

RDB檔案儲存過程

• redis呼叫fork,現在有了子程序和父程序。
• 父程序繼續處理client請求，子程序負責將記憶體內容寫入到臨時檔案。由於os的寫時複製機制（copy on write)父子程序會共享相同的物理頁面，當父程序處理寫請求時os會為父程序要修改的頁面建立副本，而不是寫共享的頁面。所以子程序的地址空間內的數 據是fork時刻整個資料庫的一個快照。
• 當子程序將快照寫入臨時檔案完畢後，用臨時檔案替換原來的快照檔案，然後子程序退出。

client 也可以使用save或者bgsave命令通知redis做一次快照持久化。save操作是在主執行緒中儲存快照的，由於redis是用一個主執行緒來處理所有 client的請求，這種方式會阻塞所有client請求。所以不推薦使用。

另一點需要注意的是，每次快照持久化都是將記憶體資料完整寫入到磁碟一次，並不 是增量的只同步髒資料。如果資料量大的話，而且寫操作比較多，必然會引起大量的磁碟io操作，可能會嚴重影響效能。

優勢

• 一旦採用該方式，那麼你的整個Redis資料庫將只包含一個檔案，這樣非常方便進行備份。比如你可能打算沒1天歸檔一些資料。
• 方便備份，我們可以很容易的將一個一個RDB檔案移動到其他的儲存介質上
• RDB 在恢復大資料集時的速度比 AOF 的恢復速度要快。
• RDB 可以最大化 Redis 的效能：父程序在儲存 RDB 檔案時唯一要做的就是 fork 出一個子程序，然後這個子程序就會處理接下來的所有儲存工作，父程序無須執行任何磁碟 I/O 操作。

劣勢

• 如果你需要儘量避免在伺服器故障時丟失資料，那麼 RDB 不適合你。 雖然 Redis 允許你設定不同的儲存點（save point）來控制儲存 RDB 檔案的頻率， 但是， 因為RDB 檔案需要儲存整個資料集的狀態， 所以它並不是一個輕鬆的操作。 因此你可能會至少 5 分鐘才儲存一次 RDB 檔案。 在這種情況下， 一旦發生故障停機， 你就可能會丟失好幾分鐘的資料。
• 每次儲存 RDB 的時候，Redis 都要 fork() 出一個子程序，並由子程序來進行實際的持久化工作。 在資料集比較龐大時， fork() 可能會非常耗時，造成伺服器在某某毫秒內停止處理客戶端； 如果資料集非常巨大，並且 CPU 時間非常緊張的話，那麼這種停止時間甚至可能會長達整整一秒。 雖然 AOF 重寫也需要進行 fork() ，但無論 AOF 重寫的執行間隔有多長，資料的耐久性都不會有任何損失。

AOF檔案儲存過程

redis會將每一個收到的寫命令都通過write函式追加到檔案中(預設是 appendonly.aof)。

當redis重啟時會通過重新執行檔案中儲存的寫命令來在記憶體中重建整個資料庫的內容。當然由於os會在核心中快取 write做的修改，所以可能不是立即寫到磁碟上。這樣aof方式的持久化也還是有可能會丟失部分修改。不過我們可以通過配置檔案告訴redis我們想要 通過fsync函式強制os寫入到磁碟的時機。有三種方式如下（預設是：每秒fsync一次）

appendonly yes              //啟用aof持久化方式
# appendfsync always      //每次收到寫命令就立即強制寫入磁碟，最慢的，但是保證完全的持久化，不推薦使用
appendfsync everysec     //每秒鐘強制寫入磁碟一次，在效能和持久化方面做了很好的折中，推薦
# appendfsync no    //完全依賴os，效能最好,持久化沒保證

aof 的方式也同時帶來了另一個問題。持久化檔案會變的越來越大。例如我們呼叫incr test命令100次，檔案中必須儲存全部的100條命令，其實有99條都是多餘的。因為要恢復資料庫的狀態其實檔案中儲存一條set test 100就夠了。

為了壓縮aof的持久化檔案。redis提供了bgrewriteaof重寫命令。收到此命令redis將使用與快照類似的方式將記憶體中的資料 以命令的方式儲存到臨時檔案中，最後替換原來的檔案。具體過程如下

• redis呼叫fork ，現在有父子兩個程序
• 子程序根據記憶體中的資料庫快照，往臨時檔案中寫入重建資料庫狀態的命令
• 父程序繼續處理client請求，除了把寫命令寫入到原來的aof檔案中。同時把收到的寫命令快取起來。這樣就能保證如果子程序重寫失敗的話並不會出問題。
• 當子程序把快照內容寫入已命令方式寫到臨時檔案中後，子程序發訊號通知父程序。然後父程序把快取的寫命令也寫入到臨時檔案。
• 現在父程序可以使用臨時檔案替換老的aof檔案，並重命名，後面收到的寫命令也開始往新的aof檔案中追加。

需要注意到是重寫aof檔案的操作，並沒有讀取舊的aof檔案，而是將整個記憶體中的資料庫內容用命令的方式重寫了一個新的aof檔案,這點和快照有點類似。

優勢

• 使用 AOF 持久化會讓 Redis 變得非常耐久（much more durable）：你可以設定不同的 fsync 策略，比如無 fsync ，每秒鐘一次 fsync ，或者每次執行寫入命令時 fsync 。 AOF 的預設策略為每秒鐘 fsync 一次，在這種配置下，Redis 仍然可以保持良好的效能，並且就算髮生故障停機，也最多隻會丟失一秒鐘的資料（ fsync 會在後臺執行緒執行，所以主執行緒可以繼續努力地處理命令請求）。

• AOF 檔案是一個只進行追加操作的日誌檔案（append only log）， 因此對 AOF 檔案的寫入不需要進行 seek ， 即使日誌因為某些原因而包含了未寫入完整的命令（比如寫入時磁碟已滿，寫入中途停機，等等）， redis-check-aof 工具也可以輕易地修復這種問題。
  Redis 可以在 AOF 檔案體積變得過大時，自動地在後臺對 AOF 進行重寫： 重寫後的新 AOF 檔案包含了恢復當前資料集所需的最小命令集合。 整個重寫操作是絕對安全的，因為 Redis 在建立新 AOF 檔案的過程中，會繼續將命令追加到現有的 AOF 檔案裡面，即使重寫過程中發生停機，現有的 AOF 檔案也不會丟失。 而一旦新 AOF 檔案建立完畢，Redis 就會從舊 AOF 檔案切換到新 AOF 檔案，並開始對新 AOF 檔案進行追加操作。

• AOF 檔案有序地儲存了對資料庫執行的所有寫入操作， 這些寫入操作以 Redis 協議的格式儲存， 因此 AOF 檔案的內容非常容易被人讀懂， 對檔案進行分析（parse）也很輕鬆。 匯出（export） AOF 檔案也非常簡單： 舉個例子， 如果你不小心執行了 FLUSHALL 命令， 但只要 AOF 檔案未被重寫， 那麼只要停止伺服器， 移除 AOF 檔案末尾的 FLUSHALL 命令， 並重啟 Redis ， 就可以將資料集恢復到 FLUSHALL 執行之前的狀態。

劣勢

• 對於相同的資料集來說，AOF 檔案的體積通常要大於 RDB 檔案的體積。

• 根據所使用的 fsync 策略，AOF 的速度可能會慢於 RDB 。 在一般情況下， 每秒 fsync 的效能依然非常高， 而關閉 fsync 可以讓 AOF 的速度和 RDB 一樣快， 即使在高負荷之下也是如此。 不過在處理巨大的寫入載入時，RDB 可以提供更有保證的最大延遲時間（latency）。

• AOF 在過去曾經發生過這樣的 bug ： 因為個別命令的原因，導致 AOF 檔案在重新載入時，無法將資料集恢復成儲存時的原樣。 （舉個例子，阻塞命令 BRPOPLPUSH 就曾經引起過這樣的 bug 。） 測試套件裡為這種情況添加了測試： 它們會自動生成隨機的、複雜的資料集， 並通過重新載入這些資料來確保一切正常。 雖然這種 bug 在 AOF 檔案中並不常見， 但是對比來說， RDB 幾乎是不可能出現這種 bug 的。

抉擇

一般來說， 如果想達到足以媲美 PostgreSQL 的資料安全性， 你應該同時使用兩種持久化功能。

如果你的資料可以承受數分鐘以內的丟失， 那麼你可以只使用 RDB 持久化。

其餘情況我個人喜好選擇AOF（雖然效率低一些，但是安全，方便閱讀）。

三

1. Snapshotting:
預設情況下，Redis會將資料集的快照dump到dump.rdb檔案中。此外，我們也可以通過配置檔案來修改Redis伺服器dump快照的頻率，在開啟6379.conf檔案之後，我們搜尋save，可以看到下面的配置資訊：
save 900 1 #在900秒(15分鐘)之後，如果至少有1個key發生變化，則dump記憶體快照。
save 300 10 #在300秒(5分鐘)之後，如果至少有10個key發生變化，則dump記憶體快照。
save 60 10000 #在60秒(1分鐘)之後，如果至少有10000個key發生變化，則dump記憶體快照。

2. Dump快照的機制：
1). Redis先fork子程序。
2). 子程序將快照資料寫入到臨時RDB檔案中。
3). 當子程序完成資料寫入操作後，再用臨時檔案替換老的檔案。

5.4.3. AOF檔案：
上面已經多次講過，RDB的快照定時dump機制無法保證很好的資料永續性。如果我們的應用確實非常關注此點，我們可以考慮使用Redis中的AOF機制。對於Redis伺服器而言，其預設的機制是RDB，如果需要使用AOF，則需要修改配置檔案中的以下條目：
將appendonly no改為appendonly yes
從現在起，Redis在每一次接收到資料修改的命令之後，都會將其追加到AOF檔案中。在Redis下一次重新啟動時，需要載入AOF檔案中的資訊來構建最新的資料到記憶體中。

5.4.5. AOF的配置：
在Redis的配置檔案中存在三種同步方式，它們分別是：
appendfsync always #每次有資料修改發生時都會寫入AOF檔案。
appendfsync everysec #每秒鐘同步一次，該策略為AOF的預設策略。
appendfsync no #從不同步。高效但是資料不會被持久化。

5.4.6. 如何修復壞損的AOF檔案：
1). 將現有已經壞損的AOF檔案額外拷貝出來一份。
2). 執行"redis-check-aof --fix <filename>"命令來修復壞損的AOF檔案。
3). 用修復後的AOF檔案重新啟動Redis伺服器。

5.4.7. Redis的資料備份：
在Redis中我們可以通過copy的方式線上備份正在執行的Redis資料檔案。這是因為RDB檔案一旦被生成之後就不會再被修改。Redis每次都是將最新的資料dump到一個臨時檔案中，之後在利用rename函式原子性的將臨時檔案改名為原有的資料檔名。因此我們可以說，在任意時刻copy資料檔案都是安全的和一致的。鑑於此，我們就可以通過建立cron job的方式定時備份Redis的資料檔案，並將備份檔案copy到安全的磁碟介質中。

5.5、立即寫入

//立即儲存，同步儲存
    public static void syncSave() throws Exception{
        Jedis jedis=new Jedis("127.0.0.1",6379);
        for (int i = 0; i <1000; i++) {
            jedis.set("key"+i, "Hello"+i);
            System.out.println("設定key"+i+"的資料到redis");
            Thread.sleep(2);
        }
        //執行儲存，會在伺服器下生成一個dump.rdb資料庫檔案
        jedis.save();
        jedis.close();
        System.out.println("寫入完成");
    }

執行結果：

這裡的save方法是同步的，沒有寫入完成前不執行後面的程式碼。

5.6、非同步寫入

    //非同步儲存
    public static void asyncSave() throws Exception{
        Jedis jedis=new Jedis("127.0.0.1",6379);
        for (int i = 0; i <1000; i++) {
            jedis.set("key"+i, "Hello"+i);
            System.out.println("設定key"+i+"的資料到redis");
            Thread.sleep(2);
        }
        //執行非同步儲存，會在伺服器下生成一個dump.rdb資料庫檔案
        jedis.bgsave();
        jedis.close();
        System.out.println("寫入完成");
    }

如果資料量非常大，要儲存的內容很多，建議使用bgsave，如果內容少則可以使用save方法。關於各方式的比較源自網友的部落格。

1、Redis的第一個持久化策略：RDB快照 

Redis支援將當前資料的快照存成一個數據檔案的持久化機制。而一個持續寫入的資料庫如何生成快照呢。Redis藉助了fork命令的copy on write機制。在生成快照時，將當前程序fork出一個子程序，然後在子程序中迴圈所有的資料，將資料寫成為RDB檔案。 

我們可以通過Redis的save指令來配置RDB快照生成的時機，比如你可以配置當10分鐘以內有100次寫入就生成快照，也可以配置當1小時內有1000次寫入就生成快照，也可以多個規則一起實施。這些規則的定義就在Redis的配置檔案中，你也可以通過Redis的CONFIG SET命令在Redis執行時設定規則，不需要重啟Redis。 

Redis的RDB檔案不會壞掉，因為其寫操作是在一個新程序中進行的，當生成一個新的RDB檔案時，Redis生成的子程序會先將資料寫到一個臨時檔案中，然後通過原子性rename系統呼叫將臨時檔案重新命名為RDB檔案，這樣在任何時候出現故障，Redis的RDB檔案都總是可用的。 

同時，Redis的RDB檔案也是Redis主從同步內部實現中的一環。 

但是，我們可以很明顯的看到，RDB有它的不足，就是一旦資料庫出現問題，那麼我們的RDB檔案中儲存的資料並不是全新的，從上次RDB檔案生成到 Redis停機這段時間的資料全部丟掉了。在某些業務下，這是可以忍受的，我們也推薦這些業務使用RDB的方式進行持久化，因為開啟RDB的代價並不高。 但是對於另外一些對資料安全性要求極高的應用，無法容忍資料丟失的應用，RDB就無能為力了，所以Redis引入了另一個重要的持久化機制：AOF日誌。 

2、Redis的第二個持久化策略：AOF日誌 

AOF日誌的全稱是Append Only File，從名字上我們就能看出來，它是一個追加寫入的日誌檔案。與一般資料庫不同的是，AOF檔案是可識別的純文字，它的內容就是一個個的Redis標準命令。比如我們進行如下實驗，使用Redis2.6 版本，在啟動命令引數中設定開啟AOF功能：

　　然後我們執行如下的命令：

　　這時我們檢視AOF日誌檔案，就會得到如下內容：

　　可以看到，寫操作都生成了一條相應的命令作為日誌。其中值得注意的是最後一個del命令，它並沒有被記錄在AOF日誌中，這是因為Redis判斷出 這個命令不會對當前資料集做出修改。所以不需要記錄這個無用的寫命令。另外AOF日誌也不是完全按客戶端的請求來生成日誌的，比如命令 INCRBYFLOAT 在記AOF日誌時就被記成一條SET記錄，因為浮點數操作可能在不同的系統上會不同，所以為了避免同一份日誌在不同的系統上生成不同的資料集，所以這裡只將操作後的結果通過SET來記錄。 

AOF重寫 

你可以會想，每一條寫命令都生成一條日誌，那麼AOF檔案是不是會很大？答案是肯定的，AOF檔案會越來越大，所以Redis又提供了一個功能，叫做AOF rewrite。其功能就是重新生成一份AOF檔案，新的AOF檔案中一條記錄的操作只會有一次，而不像一份老檔案那樣，可能記錄了對同一個值的多次操作。其生成過程和RDB類似，也是fork一個程序，直接遍歷資料，寫入新的AOF臨時檔案。在寫入新檔案的過程中，所有的寫操作日誌還是會寫到原來老的 AOF檔案中，同時還會記錄在記憶體緩衝區中。當重完操作完成後，會將所有緩衝區中的日誌一次性寫入到臨時檔案中。然後呼叫原子性的rename命令用新的 AOF檔案取代老的AOF檔案。 

二、Redis持久化效能是否可靠？ 

從上面的流程我們能夠看到，RDB是順序IO操作，效能很高。而同時在通過RDB檔案進行資料庫恢復的時候，也是順序的讀取資料載入到記憶體中。所以也不會造成磁碟的隨機讀取錯誤。 

而AOF是一個寫檔案操作，其目的是將操作日誌寫到磁碟上，所以它也同樣會遇到我們上面說的寫操作的5個流程。那麼寫AOF的操作安全性又有多高呢？實際上這是可以設定的，在Redis中對AOF呼叫write寫入後，何時再呼叫fsync將其寫到磁碟上，通過appendfsync選項來控制，下面appendfsync的三個設定項，安全強度逐漸變強。 

1、appendfsync no 

當設定appendfsync為no的時候，Redis不會主動呼叫fsync去將AOF日誌內容同步到磁碟，所以這一切就完全依賴於作業系統的除錯了。對大多數Linux作業系統，是每30秒進行一次fsync，將緩衝區中的資料寫到磁碟上。 

2、appendfsync everysec 

當設定appendfsync為everysec的時候，Redis會預設每隔一秒進行一次fsync呼叫，將緩衝區中的資料寫到磁碟。但是當這一 次的fsync呼叫時長超過1秒時。Redis會採取延遲fsync的策略，再等一秒鐘。也就是在兩秒後再進行fsync，這一次的fsync就不管會執行多長時間都會進行。這時候由於在fsync時檔案描述符會被阻塞，所以當前的寫操作就會阻塞。 

所以，結論就是：在絕大多數情況下，Redis會每隔一秒進行一次fsync。在最壞的情況下，兩秒鐘會進行一次fsync操作。 

這一操作在大多數資料庫系統中被稱為group commit，就是組合多次寫操作的資料，一次性將日誌寫到磁碟。 

3、appednfsync always 

當設定appendfsync為always時，每一次寫操作都會呼叫一次fsync，這時資料是最安全的，當然，由於每次都會執行fsync，所以其效能也會受到影響。 

對於pipelining有什麼不同？ 

對於pipelining的操作，其具體過程是客戶端一次性發送N個命令，然後等待這N個命令的返回結果被一起返回。通過採用pipilining 就意味著放棄了對每一個命令的返回值確認。由於在這種情況下，N個命令是在同一個執行過程中執行的。所以當設定appendfsync為everysec 時，可能會有一些偏差，因為這N個命令可能執行時間超過1秒甚至2秒。但是可以保證的是，最長時間不會超過這N個命令的執行時間和。 

三、和其它資料庫的比較 

上面作業系統層面的資料安全我們已經講了很多，其實，不同的資料庫在實現上都大同小異。總之，最後的結論就是，在Redis開啟AOF的情況下，其單機資料安全性並不比這些成熟的SQL資料庫弱。 

在資料匯入方面的比較 

這些持久化的資料有什麼用，當然是用於重啟後的資料恢復。Redis是一個記憶體資料庫，無論是RDB還是AOF，都只是其保證資料恢復的措施。所以 Redis在利用RDB和AOF進行恢復的時候，都會讀取RDB或AOF檔案，重新載入到記憶體中。相對於MySQL等資料庫的啟動時間來說，會長很多，因為MySQL本來是不需要將資料載入到記憶體中的。 

但是相對來說，MySQL啟動後提供服務時，其被訪問的熱資料也會慢慢載入到記憶體中，通常我們稱之為預熱，而在預熱完成前，其效能都不會太高。而Redis的好處是一次性將資料載入到記憶體中，一次性預熱。這樣只要Redis啟動完成，那麼其提供服務的速度都是非常快的。 

而在利用RDB和利用AOF啟動上，其啟動時間有一些差別。RDB的啟動時間會更短，原因有兩個，一是RDB檔案中每一條資料只有一條記錄，不會像 AOF日誌那樣可能有一條資料的多次操作記錄。所以每條資料只需要寫一次就行了。另一個原因是RDB檔案的儲存格式和Redis資料在記憶體中的編碼格式是一致的，不需要再進行資料編碼工作。在CPU消耗上要遠小於AOF日誌的載入。