聊一下Redis的持久化原理

大家都知道，Redis之所以性能好，讀寫快，是因為Redis是一個內存數據庫，它的操作都幾乎基于內存。但是內存型數據庫有一個很大的弊端，就是當數據庫進程崩潰或系統重啟的時候，如果內存數據不保存的話，里面的數據就會丟失不見了。這樣的數據庫并不是一個可靠的數據庫。

所以數據的持久化是內存型數據庫的重中之重。它不僅提供數據保存硬盤的功能，還可以借此用硬盤容量擴展數據存儲空間，使得Redis的可以存儲超過機器本身內存大小的數據。

Redis對于數據持久化提供了兩種持久化的方案，RDB與AOF。它們的原理和使用場景都大不相同，下面我們來詳細地了解下。

聊聊redis持久化 – RDB

RDB方式，是將redis某一時刻的數據持久化到磁盤中，是一種快照式的持久化方法。

redis在進行數據持久化的過程中，會先將數據寫入到一個臨時文件中，待持久化過程都結束了，才會用這個臨時文件替換上次持久化好的文件。正是這種特性，讓我們可以隨時來進行備份，因為快照文件總是完整可用的。

對于RDB方式，redis會單獨創建(fork)一個子進程來進行持久化，而主進程是不會進行任何IO操作的，這樣就確保了redis極高的性能。

如果需要進行大規模數據的恢復，且對于數據恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

雖然RDB有不少優點，但它的缺點也是不容忽視的。如果你對數據的完整性非常敏感，那么RDB方式就不太適合你，因為即使你每5分鐘都持久化一次，當redis故障時，仍然會有近5分鐘的數據丟失。所以，redis還提供了另一種持久化方式，那就是AOF。

聊聊redis持久化 – AOF

AOF，英文是Append Only File，即只允許追加不允許改寫的文件。

如前面介紹的，AOF方式是將執行過的寫指令記錄下來，在數據恢復時按照從前到后的順序再將指令都執行一遍，就這么簡單。

我們通過配置redis.conf中的appendonly yes就可以打開AOF功能。如果有寫操作(如SET等)，redis就會被追加到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文件，而是報錯退出。這時可以通過以下步驟來修復出錯的文件：

備份被寫壞的AOF文件

運行redis-check-aof –fix進行修復

用diff -u來看下兩個文件的差異，確認問題點

重啟redis，加載修復后的AOF文件

RDB優缺點

優點

1. RDB是某一時間點的快照，是一個緊湊的單文件，更多用于數據備份。可以按每小時或每日來備份，方便從不同的版本恢復數據。

2. 單文件容易傳輸到遠程服務做故障恢復。

3. RDB可以Fork子進程進行持久化，使Redis可以更好地處理用戶請求。

4. 在大量數據的情況下，RDB相比較于AOF會更快的加載。

缺點

1. 如果Redis不及時保存RDB文件，會造成數據的丟失。例如系統突然斷電，但未來得及保存數據。即使你設置更多的Save point，也無法保證100%的數據不丟失。

2. RDB經常需要fork子進程去執行，但如果再大量數據的情況下，這個fork操作會非常耗CPU資源的。對比AOF雖然也是fork，但是它的數據保存處理是可以控制的，不需要全量保存。

AOF優缺點

優點

1. AOF可以設置 完全不同步、每秒同步、每次操作同，默認是每秒同步。因為AOF是操作指令的追加，所以可以頻繁的大量的同步。

2. AOF文件是一個值追加日志的文件，即使服務宕機為寫入完整的命令，也可以通過redis-check-aof工具修復這些問題。

3. 如果AOF文件過大，Redis會在后臺自動地重寫AOF文件。重寫后會使AOF文件壓縮到最小所需的指令集。

4. AOF文件是有序保存數據庫的所有寫入操作，易讀，易分析。即使如果不小心誤操作數據庫，也很容易找出錯誤指令，恢復到某個數據節點。例如不小心FLUSHALL，可以非常容易恢復到執行命令之前。

缺點

1. 相同數據量下，AOF的文件通常體積會比RDB大。因為AOF是存指令的，而RDB是所有指令的結果快照。但AOF在日志重寫后會壓縮一些空間。

2. 在大量寫入和載入的時候，AOF的效率會比RDB低。因為大量寫入，AOF會執行更多的保存命令，載入的時候也需要大量的重執行命令來得到最后的結果。RDB對此更有優勢。

參考文獻

總結

以上是生活随笔為你收集整理的rdf mysql持久化l_Redis进阶（数据持久化RDF和AOF）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。