5分鐘完全理解Redis持久化

Redis持久化

RDB快照

在默認狀況下，Redis將內存數據庫快照保存到dump.rdb的二進制文件中。
能夠對Redis進行設置，讓它在「N秒內數據集至少有N個改動」， 這一條件被知足時，自動保存一次數據集。好比說：讓Redis知足「60秒內至少有1000個鍵被改動」這一個條件時，自動保存一次數據集。

save 60 1000

除了在配置文件中使用save關鍵字設置RDB快照，還能夠在命令行中手動執行命令生成RDB快照，進入redis客戶端執行命令save或bgsave能夠生成dump.rdb文件。
每次執行命令都會將全部redis內存快照保存到一個rdb文件裏，並覆蓋原有的rdb快照文件。
save是同步命令，bgsave是異步命令，bgsave會從redis主進程fork出一個子進程專門用來生成rdb二進制文件。

AOF（append only file）

快照功能並非很是durable，若是redis由於某些緣由而形成故障停機，那麼服務器將丟失最近寫入且未保存到快照中的那些數據。從1.1版本，redis增長了一種徹底durable的方式：AOF持久化，將修改的每一條指令記錄進appendonly.aof中。修改配置文件來打開aof功能：

appendonly yes

打開aof功能，每當redis執行一個改變數據集的命令時，這個命令就會追加到aof文件的末尾。這樣的話，當redis從新啓動時，程序就會經過執行aof文件中的命令來達到重建數據集的目的。
能夠配置redis多久纔將命令持久化到磁盤一次。

appendfsync always：每次有新命令追加到aof文件時就執行一個持久化，很是慢可是安全
appendfsync everysec：每秒執行一次持久化，足夠快（和使用rdb持久化差很少）而且在故障時只會丟失1秒鐘的數據
appendfsync no：從不持久化，將數據交給操做系統來處理。redis處理命令速度加快可是不安全。

默認狀況下 ，每秒執行一次fsync， 這種fsync策略能夠兼顧安全性和速度。
rdb和aof的區別：

redis啓動時若是既有rdb文件又有aof文件則優先選擇aof文件恢復數據，由於aof文件通常來講數據更安全一點。

2、AOF重寫
aof文件裏可能有太多「瑣碎」指令，因此aof會按期根據內存的最新數據從新生成aof文件
有兩個配置能夠控制aof自動重寫的頻率：

auto-aof-rewrite-min-size 64mb： aof文件至少要達到64m纔會觸發制動重寫，文件過小恢復速度原本就很快，重寫的意義不大

auto-aof-rewrite-percentage 100：aof文件上一次重寫後文件大小增加了100%則再次觸發重寫

固然aof還能夠手動重寫，進入redis客戶端執行命令bgrewriteaof重寫aof。
觸發aof重寫時，redis會fork一個子進程去作，不會對redis正常命令處理有太多影響。

Redis 4.0混合持久化

重啓redis恢復數據集時，不多會使用rdb來恢復內存狀態，由於會丟失大量數據。一般會使用aof日誌恢復數據，可是重放aof日誌性能相對rdb來講要慢不少，這樣在redis實例很大的狀況下，啓動須要花費很長時間。Redis4.0爲了解決這個問題，帶來了新的持久化選項——混合持久化。

aof-use-rdb-preamble yes

混合持久化aof文件結構：

若是開啓了混合持久化，aof在重寫時，再也不是單純將內存數據轉換爲RESP命令寫入aof文件，而是將重寫這一刻以前的內存作rdb快照處理，而且將rdb快照內容和增量的aof修改內存數據的命令存在一塊兒，都寫入新的aof文件，新的aof文件一開始不叫appendonly.aof，等到重寫完成後，新的aof文件纔會進行更名，原子的覆蓋原有的aof文件，完成新舊兩個aof文件的替換。
因而在redis重啓的時候，能夠先加載rdb文件，而後再重放增量的aof日誌就能夠徹底替代以前的aof全量文件重放，所以重啓效率大幅獲得提升。

還沒關注個人公衆號？

• 掃文末二維碼關注公衆號【小強的進階之路】可領取以下:
• 學習資料： 1T視頻教程：涵蓋Javaweb先後端教學視頻、機器學習/人工智能教學視頻、Linux系統教程視頻、雅思考試視頻教程；
• 100多本書：包含C/C++、Java、Python三門編程語言的經典必看圖書、LeetCode題解大全；
• 軟件工具：幾乎包括你在編程道路上的可能會用到的大部分軟件；
• 項目源碼：20個JavaWeb項目源碼。