redis資料的兩種持久化方式rdb和aof對比(一)
原文參考：https://www.jb51.net/article/121848.htm
Redis是我們開發中常用的資料庫，今天和大家分享的就是redis持久化的2種方式：RDB（Redis DataBase）和AOF（Apend Only File），希望對大家學習redis有幫助，一起來看看吧。
一.概念介紹
redis提供了兩種持久化的方式，分別是RDB（Redis DataBase）和AOF（Apend Only File）。
RDB方式
RDB方式是一種快照式的持久化方法，將某一時刻的資料持久化到磁碟中。
•redis在進行資料持久化的過程中，會先將資料寫入到一個臨時檔案中，待持久化過程都結束了，才會用這個臨時檔案替換上次持久化好的檔案。正是這種特性，讓我們可以隨時來進行備份，因為快照檔案總是完整可用的。
•對於RDB方式，redis會單獨建立（fork）一個子程序來進行持久化，而主程序是不會進行任何IO操作的，這樣就確保了redis極高的效能。
•如果需要進行大規模資料的恢復，且對於資料恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
AOF方式
AOF方式是將執行過的寫指令記錄下來，在資料恢復時按照叢前到後的順序再將指令執行一遍。
•AOF命令以redis協議追加儲存每次寫的操作到檔案末尾.Redis還能對AOF檔案進行後臺重寫,使得AOF檔案的體積不至於過大.預設的AOF持久化策略是每秒鐘fsync一次（fsync是指把快取中的寫指令記錄到磁碟中），因為在這種情況下，redis仍然可以保持很好的處理效能，即使redis故障，也只會丟失最近1秒鐘的資料。
•如果在追加日誌時，恰好遇到磁碟空間滿、inode滿或斷電等情況導致日誌寫入不完整，也沒有關係，redis提供了redis-check-aof工具，可以用來進行日誌修復。
•因為採用了追加方式，如果不做任何處理的話，AOF檔案會變得越來越大，為此，redis提供了AOF檔案重寫（rewrite）機制，即當AOF檔案的大小超過所設定的閾值時，redis就會啟動AOF檔案的內容壓縮，只保留可以恢復資料的最小指令集。舉個例子或許更形象，假如我們呼叫了100次INCR指令，在AOF檔案中就要儲存100條指令，但這明顯是很低效的，完全可以把這100條指令合併成一條SET指令，這就是重寫機制的原理。
•在進行AOF重寫時，仍然是採用先寫臨時檔案，全部完成後再替換的流程，所以斷電、磁碟滿等問題都不會影響AOF檔案的可用性。
二. 兩種方式優缺點
1. RDB方式
•優點：
1.RDB是一個單一的緊湊檔案,它儲存了某個時間點得資料集,非常適用於資料集的備份,比如你可以在每個小時報儲存一下過去24小時內的資料,同時每天儲存過去30天的資料,這樣即使出了問題你也可以根據需求恢復到不同版本的資料集.
2.RDB是一個緊湊的單一檔案,方便傳送，適用於災難恢復.
3.RDB在儲存RDB檔案時父程序唯一需要做的就是fork出一個子程序,接下來的工作全部由子程序來做，父程序不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的效能.
4.與AOF相比,在恢復大的資料集的時候，RDB方式會更快一些.
•缺點：
1.Redis意外宕機,可能會丟失幾分鐘的資料（取決於配置的save時間點）。RDB方式需要儲存珍整個資料集，是一個比較繁重的工作，通常需要設定5分鐘或者更久做一次完整的儲存。
2.RDB 需要經常fork子程序來儲存資料集到硬碟上,當資料集比較大的時候,fork的過程是非常耗時的,可能會導致Redis在一些毫秒級內不能響應客戶端的請求.如果資料集巨大並且CPU效能不是很好的情況下,這種情況會持續更久。
2. AOF方式
•優點
1.使用AOF 會讓Redis資料更加耐久: 你可以使用不同的fsync策略：無fsync,每秒fsync,每次寫的時候fsync.使用預設的每秒fsync策略,Redis的效能依然很好(fsync是由後臺執行緒進行處理的,主執行緒會盡力處理客戶端請求),一旦出現故障，你最多丟失1秒的資料.
2.AOF檔案是一個只進行追加的日誌檔案,所以不需要寫入seek,即使由於某些原因(磁碟空間已滿，寫的過程中宕機等等)未執行完整的寫入命令,你也也可使用redis-check-aof工具修復這些問題.
3.Redis 可以在 AOF 檔案體積變得過大時，自動地在後臺對 AOF 進行重寫： 重寫後的新 AOF 檔案包含了恢復當前資料集所需的最小命令集合。 整個重寫操作是絕對安全的，因為 Redis 在建立新 AOF 檔案的過程中，會繼續將命令追加到現有的 AOF 檔案裡面，即使重寫過程中發生停機，現有的 AOF 檔案也不會丟失。 而一旦新 AOF 檔案建立完畢，Redis 就會從舊 AOF 檔案切換到新 AOF 檔案，並開始對新 AOF 檔案進行追加操作。
4.AOF 檔案有序地儲存了對資料庫執行的所有寫入操作， 這些寫入操作以 Redis 協議的格式儲存， 因此 AOF 檔案的內容非常容易被人讀懂， 對檔案進行分析也很輕鬆。 匯出AOF 檔案也非常簡單： 舉個例子， 如果你不小心執行了 FLUSHALL 命令， 但只要 AOF 檔案未被重寫， 那麼只要停止伺服器， 移除 AOF 檔案末尾的 FLUSHALL 命令， 並重啟 Redis ， 就可以將資料集恢復到 FLUSHALL 執行之前的狀態。
•缺點
1.對於相同的資料集來說，AOF 檔案的體積通常要大於 RDB 檔案的體積。
2.根據所使用的 fsync 策略，AOF 的速度可能會慢於 RDB 。 在一般情況下， 每秒 fsync 的效能依然非常高， 而關閉 fsync 可以讓 AOF 的速度和 RDB 一樣快， 即使在高負荷之下也是如此。 不過在處理巨大的寫入載入時，RDB 可以提供更有保證的最大延遲時間。
三. 配置方式
1. RDB配置方式
預設情況下，是快照rdb的持久化方式，將記憶體中的資料以快照的方式寫入二進位制檔案中，預設的檔名是dump.rdb
redis.conf配置：
| 1 2 3 |
save 900 1
save 300 10
save 60 10000
|
以上是預設配置：900秒之內，如果超過1個key被修改，則發起快照儲存；
300秒內，如果超過10個key被修改，則發起快照儲存 ；
1分鐘之內，如果1萬個key被修改，則發起快照儲存 ；
這種方式不能完全保證資料持久化，因為是定時儲存，所以當redis服務down掉，就會丟失一部分資料，而且資料量大，寫操作多的情況下，會引起大量的磁碟IO操作，會影響效能。
所以，如果這兩種方式同時開啟，如果對資料進行恢復，不應該用rdb持久化方式對資料庫進行恢復。
2. AOF 配置方式
使用aof做持久化，每一個寫命令都通過write函式追加到appendonly.aof中.
配置方式：啟動aof持久化的方式
appendonly yes