1，什麼是持久化？
持久化就是將數據寫到磁盤中去，防止服務宕機，造成數據丟失。
2，持久化方式？
redis是把數據放到內存中的，因爲到內存中所以快，但是容易丟失。但是redis提供了持久化的方式。RBD和AOF。
（1）RDB
rdb是Redis DataBase的縮寫。RDB是在指定時間將內存中的數據集快照寫入磁盤，實際操作過程是fork一個子進程，先將數據集寫入臨時文件，寫入成功後，再替換之前的文件，用二進制壓縮存儲。
（2）AOF
AOF持久化的方式是記錄每次對服務器的寫操作，當服務器重啓的時候就會重新執行這些命令來恢復原始的數據，AOF命令以redis協議追加保存每次寫的操作到文件末尾，Redis還能對AOF文件進行後臺重寫，使得AOF文件的體積不易過大。
RDB的優點
- RDB是一個非常緊湊的文件,它保存了某個時間點得數據集,非常適用於數據集的備份,比如你可以在每個小時報保存一下過去24小時內的數據,同時每天保存過去30天的數據,這樣即使出了問題你也可以根據需求恢復到不同版本的數據集.
- RDB是一個緊湊的單一文件,很方便傳送到另一個遠端數據中心或者亞馬遜的S3（可能加密），非常適用於災難恢復.
- RDB在保存RDB文件時父進程唯一需要做的就是fork出一個子進程,接下來的工作全部由子進程來做，父進程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能.
- 與AOF相比,在恢復大的數據集的時候，RDB方式會更快一些.
RDB的缺點
- 如果你希望在redis意外停止工作（例如電源中斷）的情況下丟失的數據最少的話，那麼RDB不適合你.雖然你可以配置不同的save時間點(例如每隔5分鐘並且對數據集有100個寫的操作),是Redis要完整的保存整個數據集是一個比較繁重的工作,你通常會每隔5分鐘或者更久做一次完整的保存,萬一在Redis意外宕機,你可能會丟失幾分鐘的數據.
- RDB需要經常fork子進程來保存數據集到硬盤上,當數據集比較大的時候,fork的過程是非常耗時的,可能會導致Redis在一些毫秒級內不能響應客戶端的請求.如果數據集巨大並且CPU性能不是很好的情況下,這種情況會持續1秒,AOF也需要fork,但是你可以調節重寫日誌文件的頻率來提高數據集的耐久度.
AOF 優點
- 使用AOF 會讓你的Redis更加耐久:
你可以使用不同的fsync策略：無fsync,每秒fsync,每次寫的時候fsync.使用默認的每秒fsync策略,Redis的性能依然很好(fsync是由後臺線程進行處理的,主線程會盡力處理客戶端請求),一旦出現故障，你最多丟失1秒的數據.
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 缺點
- 對於相同的數據集來說，AOF 文件的體積通常要大於 RDB 文件的體積。
- 根據所使用的 fsync 策略，AOF 的速度可能會慢於 RDB 。 在一般情況下， 每秒 fsync 的性能依然非常高， 而關閉
fsync 可以讓 AOF 的速度和 RDB 一樣快， 即使在高負荷之下也是如此。 不過在處理巨大的寫入載入時，RDB
可以提供更有保證的最大延遲時間（latency）。
如何選擇使用哪種持久化方式？
一般來說， 如果想達到足以媲美 PostgreSQL 的數據安全性， 你應該同時使用兩種持久化功能。
如果你非常關心你的數據， 但仍然可以承受數分鐘以內的數據丟失， 那麼你可以只使用 RDB 持久化。
有很多用戶都只使用 AOF 持久化， 但我們並不推薦這種方式： 因爲定時生成 RDB 快照（snapshot）非常便於進行數據庫備份， 並且 RDB 恢復數據集的速度也要比 AOF 恢復的速度要快， 除此之外， 使用 RDB 還可以避免之前提到的 AOF 程序的 bug 。
工作原理
AOF 重寫和 RDB 創建快照一樣，都巧妙地利用了寫時複製機制:
- Redis 執行 fork() ，現在同時擁有父進程和子進程。
- 子進程開始將新 AOF 文件的內容寫入到臨時文件。
- 對於所有新執行的寫入命令，父進程一邊將它們累積到一個內存緩存中，一邊將這些改動追加到現有 AOF
文件的末尾,這樣樣即使在重寫的中途發生停機，現有的 AOF 文件也還是安全的。 - 當子進程完成重寫工作時，它給父進程發送一個信號，父進程在接收到信號之後，將內存緩存中的所有數據追加到新 AOF 文件的末尾
。