【聊聊redis持久化 – 兩種方式】
rdb，簡而言之，就是在不同的時間點，將redis儲存的資料生成快照並儲存到磁碟等介質上；
aof，則是換了乙個角度來實現持久化，那就是將redis執行過的所有寫指令記錄下來，在下次redis重新啟動時，只要把這些寫指令從前到後再重複執行一遍，就可以實現資料恢復了。
其實rdb和aof兩種方式也可以同時使用，在這種情況下，如果redis重啟的話，則會優先採用aof方式來進行資料恢復，這是因為aof方式的資料恢復完整度更高。
如果你沒有資料持久化的需求，也完全可以關閉rdb和aof方式，這樣的話，redis將變成乙個純記憶體資料庫，就像memcache一樣。
【聊聊redis持久化 – rdb】
rdb方式，是將redis某一時刻的資料持久化到磁碟中，是一種快照式的持久化方法。
redis在進行資料持久化的過程中，會先將資料寫入到乙個臨時檔案中，待持久化過程都結束了，才會用這個臨時檔案替換上次持久化好的檔案。正是這種特性，讓我們可以隨時來進行備份，因為快照檔案總是完整可用的。
對於rdb方式，redis會單獨建立（fork）乙個子程序來進行持久化，而主程序是不會進行任何io操作的，這樣就確保了redis極高的效能。
如果需要進行大規模資料的恢復，且對於資料恢復的完整性不是非常敏感，那rdb方式要比aof方式更加的高效。
雖然rdb有不少優點，但它的缺點也是不容忽視的。如果你對資料的完整性非常敏感，那麼rdb方式就不太適合你，因為即使你每5分鐘都持久化一次，當redis故障時，仍然會有近5分鐘的資料丟失。所以，redis還提供了另一種持久化方式，那就是aof。
【聊聊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檔案的可用性，這點大家可以放心。
aof方式的另乙個好處，我們通過乙個「場景再現」來說明。某同學在操作redis時，不小心執行了flushall，導致redis記憶體中的資料全部被清空了，這是很悲劇的事情。不過這也不是世界末日，只要redis配置了aof持久化方式，且aof檔案還沒有被重寫（rewrite），我們就可以用最快的速度暫停redis並編輯aof檔案，將最後一行的flushall命令刪除，然後重啟redis，就可以恢復redis的所有資料到flushall之前的狀態了。是不是很神奇，這就是aof持久化方式的好處之一。但是如果aof檔案已經被重寫了，那就無法通過這種方法來恢復資料了。
雖然優點多多，但aof方式也同樣存在缺陷，比如在同樣資料規模的情況下，aof檔案要比rdb檔案的體積大。而且，aof方式的恢復速度也要慢於rdb方式。
如果你直接執行bgrewriteaof命令，那麼redis會生成乙個全新的aof檔案，其中便包括了可以恢復現有資料的最少的命令集。
如果運氣比較差，aof檔案出現了被寫壞的情況，也不必過分擔憂，redis並不會貿然載入這個有問題的aof檔案，而是報錯退出。這時可以通過以下步驟來修復出錯的檔案：
1.備份被寫壞的aof檔案
2.執行redis-check-aof –fix進行修復
3.用diff -u來看下兩個檔案的差異，確認問題點
4.重啟redis，載入修復後的aof檔案
【聊聊redis持久化 – aof重寫】
aof重寫的內部執行原理，我們有必要了解一下。
在重寫即將開始之際，redis會建立（fork）乙個「重寫子程序」，這個子程序會首先讀取現有的aof檔案，並將其包含的指令進行分析壓縮並寫入到乙個臨時檔案中。
與此同時，主工作程序會將新接收到的寫指令一邊累積到記憶體緩衝區中，一邊繼續寫入到原有的aof檔案中，這樣做是保證原有的aof檔案的可用性，避免在重寫過程**現意外。
當「重寫子程序」完成重寫工作後，它會給父程序發乙個訊號，父程序收到訊號後就會將記憶體中快取的寫指令追加到新aof檔案中。
當追加結束後，redis就會用新aof檔案來代替舊aof檔案，之後再有新的寫指令，就都會追加到新的aof檔案中了。
【聊聊redis持久化 – 如何選擇rdb和aof】
對於我們應該選擇rdb還是aof，官方的建議是兩個同時使用。這樣可以提供更可靠的持久化方案。
各自的優缺點？
1）rdb(redis database)持久化方式：是指用資料集快照的方式(半持久化模式)記錄redis資料庫的所有鍵值對,在某個時間點將資料寫入乙個臨時檔案，持久化結束後，用這個臨時檔案替換上次持久化的檔案，達到資料恢復。
優點：1.只有乙個檔案dump.rdb，方便持久化。
2.容災性好，乙個檔案可以儲存到安全的磁碟。
3.效能最大化，fork子程序來完成寫操作，讓主程序繼續處理命令，所以是io最大化。(使用單獨子程序來進行持久化，主程序不會進行任何io操作，保證了redis的高效能) 4.相對於資料集大時，比aof的啟動效率更高。
缺點：1.資料安全性低。(rdb是間隔一段時間進行持久化，如果持久化之間redis發生故障，會發生資料丟失。所以這種方式更適合資料要求不嚴謹的時候)
優點：3.aof機制的rewrite模式。(aof檔案沒被rewrite之前（檔案過大時會對命令進行合併重寫），可以刪除其中的某些命令（比如誤操作的flushall）)
缺點：1.aof檔案比rdb檔案大，且恢復速度慢。
2.資料集大的時候，比rdb啟動效率低。
redis持久化 AOF持久化
1.aof持久化原理 aof持久化會將被執行的寫命令寫到aof檔案的末尾。在恢復的時候，redis只要從頭到尾重新執行一次aof檔案包含的所有寫命令 2.配置選項 固態硬碟禁用always選項，在某些情況頻繁讀寫會大大降低固態硬碟的壽命 4.aof檔案的重寫和壓縮 aof檔案裡面記錄了所有的命令而不...
redis持久化之AOF持久化
aof與rdb持久化通過儲存資料庫中的鍵值對來記錄資料庫狀態不同，aof持久化是通過儲存redis伺服器所執行的寫命令來記錄資料庫狀態的。被寫入aof檔案的所有命令都是以redis的命令請求協議格式儲存的。當aof持久化功能處於開啟狀態，伺服器在執行完乙個寫命令之後，會以協議格式將被執行的寫命令追加...
Redis（三） redis持久化
redis是支援資料持久化的，雖然在生產中經常被當做快取伺服器使用。redis持久化機制分為兩種 第一種是快照第二種是aof日誌。快照原理 前面redis基礎篇中提到，redis是單執行緒的，這個執行緒需要同時處理客戶端的請求和記憶體資料結構的邏輯讀寫，顯然難以在保持高效能的前提下完成這些工作。所以...