一篇文章完全理解Redis持久化：RDB和AOF

爲何須要持久化？

Redis對數據的操做都是基於內存的，當遇到了進程退出、服務器宕機等意外狀況，若是沒有持久化機制，那麼Redis中的數據將會丟失沒法恢復。有了持久化機制，Redis在下次重啓時能夠利用以前持久化的文件進行數據恢復。理解和掌握Redis的持久機制，對於Redis的平常開發和運維都有很大幫助，也是在大廠面試常常被問到的知識點。Redis支持的兩種持久化機制：

1. RDB：把當前數據生成快照保存在硬盤上。
2. AOF：記錄每次對數據的操做到硬盤上。

接下來，咱們詳細瞭解一下這兩種持久化機制。

歡迎關注微信公衆號：萬貓學社，每週一分享Java技術乾貨。

RDB持久化

RDB（Redis DataBase）持久化是把當前Redis中所有數據生成快照保存在硬盤上。RDB持久化能夠手動觸發，也能夠自動觸發。

手動觸發

save和bgsave命令均可以手動觸發RDB持久化。

save命令

執行save命令會手動觸發RDB持久化，可是save命令會阻塞Redis服務，直到RDB持久化完成。當Redis服務儲存大量數據時，會形成較長時間的阻塞，不建議使用。

> save
OK

執行後，Redis的日誌中記錄：

* DB saved on disk

bgsave命令

執行bgsave命令也會手動觸發RDB持久化，和save命令不一樣是：Redis服務通常不會阻塞。Redis進程會執行fork操做建立子進程，RDB持久化由子進程負責，不會阻塞Redis服務進程。Redis服務的阻塞只發生在fork階段，通常狀況時間很短。

> bgsave
Background saving started

執行後，Redis的日誌中記錄：

* Background saving started by pid 2645
 * DB saved on disk
 * RDB: 0 MB of memory used by copy-on-write
 * Background saving terminated with success

bgsave命令的具體流程以下圖：

1. 執行bgsave命令，Redis進程先判斷當前是否存在正在執行的RDB或AOF子線程，若是存在就是直接結束。
2. Redis進程執行fork操做建立子線程，在fork操做的過程當中Redis進程會被阻塞。
3. Redis進程fork完成後，bgsave命令就結束了，自此Redis進程不會被阻塞，能夠響應其餘命令。
4. 子進程根據Redis進程的內存生成快照文件，並替換原有的RDB文件。
5. 子進程經過信號量通知Redis進程已完成。

歡迎關注微信公衆號：萬貓學社，每週一分享Java技術乾貨。

自動觸發

除了執行以上命令手動觸發之外，Redis內部能夠自動觸發RDB持久化。自動觸發的RDB持久化都是採用bgsave的方式，減小Redis進程的阻塞。那麼，在什麼場景下會自動觸發呢？

1. 在配置文件中設置了save的相關配置，如sava m n，它表示在m秒內數據被修改過n次時，自動觸發bgsave操做。
2. 當從節點作全量複製時，主節點會自動執行bgsave操做，而且把生成的RDB文件發送給從節點。
3. 執行debug reload命令時，也會自動觸發bgsave操做。
4. 執行shutdown命令時，若是沒有開啓AOF持久化也會自動觸發bgsave操做。

RDB優勢

RDB文件是一個緊湊的二進制壓縮文件，是Redis在某個時間點的所有數據快照。因此使用RDB恢復數據的速度遠遠比AOF的快，很是適合備份、全量複製、災難恢復等場景。

RDB缺點

每次進行bgsave操做都要執行fork操做建立子常常，屬於重量級操做，頻繁執行成本太高，因此沒法作到實時持久化，或者秒級持久化。

另外，因爲Redis版本的不斷迭代，存在不一樣格式的RDB版本，有可能出現低版本的RDB格式沒法兼容高版本RDB文件的問題。

歡迎關注微信公衆號：萬貓學社，每週一分享Java技術乾貨。

AOF持久化

AOF（Append Only File）持久化是把每次寫命令追加寫入日誌中，當須要恢復數據時從新執行AOF文件中的命令就能夠了。AOF解決了數據持久化的實時性，也是目前主流的Redis持久化方式。

AOF持久化流程

AOF流程以下圖：

1. 命令追加（append）：全部寫命令都會被追加到AOF緩存區（aof_buf）中。
2. 文件同步（sync）：根據不一樣策略將AOF緩存區同步到AOF文件中。
3. 文件重寫（rewrite）：按期對AOF文件進行重寫，以達到壓縮的目的。
4. 數據加載（load）：當須要恢復數據時，從新執行AOF文件中的命令。

文件同步策略

AOF持久化流程中的文件同步有如下幾個策略：

1. always：每次寫入緩存區都要同步到AOF文件中，硬盤的操做比較慢，限制了Redis高併發，不建議配置。
2. no：每次寫入緩存區後不進行同步，同步到AOF文件的操做由操做系統負責，每次同步AOF文件的週期不可控，並且增大了每次同步的硬盤的數據量。
3. eversec：每次寫入緩存區後，由專門的線程每秒鐘同步一次，作到了兼顧性能和數據安全。是建議的同步策略，也是默認的策略。

觸發文件重寫

AOF持久化流程中的文件重寫能夠手動觸發，也能夠自動觸發。

1. 手動觸發：使用bgrewriteaof命令。
2. 自動觸發：根據auto-aof-rewrite-min-size和auto-aof-rewrite-percentage配置肯定自動觸發的時機。auto-aof-rewrite-min-size表示運行AOF重寫時文件大小的最小值，默認爲64MB；auto-aof-rewrite-percentage表示當前AOF文件大小和上一次重寫後AOF文件大小的比值的最小值，默認爲100。只用前二者同時超過期纔會自動觸發文件重寫。

歡迎關注微信公衆號：萬貓學社，每週一分享Java技術乾貨。

AOF持久化配置

對AOF持久化的具體流程有了瞭解後，咱們來看一下如何配置AOF。AOF持久化默認是不開啓的，須要修改配置文件，如：

# appendonly改成yes，開啓AOF
appendonly yes
# AOF文件的名字
appendfilename "appendonly.aof"
# AOF文件的寫入方式
# everysec 每一個一秒將緩存區內容寫入文件 默認開啓的寫入方式
appendfsync everysec
# 運行AOF重寫時AOF文件大小的增加率的最小值
auto-aof-rewrite-percentage 100
# 運行AOF重寫時文件大小的最小值
auto-aof-rewrite-min-size 64mb

微信公衆號：萬貓學社

微信掃描二維碼

得到更多Java技術乾貨