Redis是一種面向“key-value”類型數據的分佈式NoSQL數據庫系統，具有高性能、持久存儲、適應高併發應用場景等優勢。它雖然起步較晚，但發展卻十分迅速。
文章主要包含二個方面：Redis持久化是如何工作的、Redis提供了RDB持久化和AOF持久化。
一、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被修改就自動做快照，下面是默認的快照保存配置
<code>save9001#900秒內如果超過1個key被修改，則發起快照保存
save30010#300秒內容如超過10個key被修改，則發起快照保存
save6010000/<code>
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一次）
<code>appendonlyyes//啟用aof持久化方式#
appendfsyncalways//每次收到寫命令就立即強制寫入磁盤，最慢的，但是保證完全的持久化，不推薦使用
appendfsynceverysec//每秒鐘強制寫入磁盤一次，在性能和持久化方面做了很好的折中，推薦#
appendfsyncno//完全依賴os，性能最好,持久化沒保證/<code>
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 持久化。
對於Redis有收集整理過一些學習筆記和Redis高頻面試題解析在這分享給大家！
由於篇幅限制，太長看下去會很乏味，也會影響閱讀體驗，下面展現將以圖片形式展示。獲取原文件以及更多資源請關注轉發分享後，後臺私信回覆【Redis】獲取資料免費領取方式！
Redis學習筆記
一、Redis 基本數據結構與實戰場景
二、Redis 常見異常及解決方案
三、分佈式環境下常見的應用場景
四、Redis 集群模式
Redis高頻常問面試題解析
一、Redis基礎概念相關問題
二、Redis 數據結構及指令相關問題
三、Redis 高併發處理策略相關問題
四、Redis 集群相關問題
五、Redis 緩存管理及持久化機制相關問題
六、Redis 應用場景設計相關問題
解析展示
閱讀更多 JavaSpring高級進階 的文章
