關於Redis 三種持久化，你須要瞭解的事兒？

Redis 持久化

前言

Rdis的讀寫都是在內存中進行，因此redis的性能很高。 持久化能夠有效地避免因進程退出而形成數據丟失問題，下次重啓的時候利用以前持久化文件能夠實現數據恢復。

持久化的幾種方式

Redis 持久化擁有如下三種方式：

• 快照方式（RDB, Redis DataBase）

RDB持久化是把當前進程數據生成快照保存到硬盤的過程，觸發RDB持久化過程分爲手動觸發和自動觸發

• 文件追加方式（AOF, Append Only File）

記錄全部的操做命令，並以文本的形式追加到文件中；

• 混合持久化方式，

Redis 4.0 以後新增的方式，混合持久化是結合了 RDB 和 AOF 的優勢，在寫入的時候，先把當前的數據以 RDB 的形式寫入文件的開頭，再將後續的操做命令以 AOF 的格式存入文件，這樣既能保證 Redis 重啓時的速度，又能減低數據丟失的風險。

以上三種持久化方案，每一種都有特定的使用場景,具體的咱們能夠根據本身的需求自行選擇。

RDB持久化

RDB（Redis DataBase）是將某一個時刻的內存快照（Snapshot），以二進制的方式寫入磁盤的過程。

RDB的持久化方式有兩種：

一種是手動觸發，一種是自動觸發

手動觸發

手動觸發Redis提供了兩個命令 ：save 和 bgsave 。

• save 命令

save 手動觸發會阻塞主線程

在客戶端執行save命令時候，就會觸發持久化，但也會使得Redis主線程阻塞，必須等到RDB持久化完成以後，纔會相應客戶端的命令，線上環境不建議使用。

下圖演示使用save命令

啓動Redis （默認配置是rdb持久化方式），rdb文件時間。

而後使用save持久化數據

而後查看持久化後rdb文件的時間 說明手動持久化文件成功

• bgsave 命令

bgsave不會阻塞主線程

使用bgsave命令時候，Redis進程執行fork操做建立子進程，RDB持久化過程由子 進程負責，完成後自動結束。阻塞只發生在fork階段，通常時間很短，基本不會發生阻塞，與save命令相比顯然bgsave更適合咱們持久化數據。

下圖表示開始自動持久化數據

自動觸發

如何自動觸發 RDB 持久化？

在redis.conf文件中有這麼一個配置

什麼意思呢？

• save m n

save m n 表示m秒內數據集存在n次修改 時，自動觸發bgsave命令。

save 900 1 則代表在 900 秒內，至少有一個鍵發生改變，就會觸發 RDB 持久化。 save 300 10 則代表在 300 秒內，至少有10個鍵發生改變，就會觸發 RDB 持久化。 save 60 10000 則代表在 60 秒內，至少有10000個鍵發生改變，就會觸發 RDB 持久化。

知足以上任意一個條件，Redis 就會自動觸發bgsvae命令進行持久化工做。

• flushall

注意：flushall 是把內存中的數據清空，持久化會把原先已經持久化的 .rdb 文件清空。

• 主從同步觸發

Redis主從複製時，當從節點執行全量複製操做時，主節點會執行 bgsave 命令，並將 RDB 文件發送給從節點，該過程會自動觸發 Redis 持久化。

RDB配置說明

# RDB 保存的條件
save 900 1
save 300 10
save 60 10000

# bgsave 失敗以後，是否中止持久化數據到磁盤，yes 表示中止持久化，no 表示忽略錯誤繼續寫文件。
stop-writes-on-bgsave-error yes

# RDB 文件壓縮 
# Redis 會採用 LZF 算法進行壓縮。若是不想消耗 CPU 性能來進行文件壓縮的話，能夠設置爲關閉此功能，# 這樣的缺點是須要更多的磁盤空間來保存文件。
rdbcompression yes

# 寫入文件和讀取文件時是否開啓 RDB 文件檢查，檢查是否有無損壞，若是在啓動是檢查發現損壞，則中止啓動。
rdbchecksum yes

# RDB 文件名
dbfilename dump.rdb

# RDB 文件目錄
dir ./

RDB 優缺點

優勢

• RDB是一個緊湊壓縮的二進制文件，表明Redis在某個時間點上的數據 快照。很是適用於備份，全量複製等場景。
• 與 AOF 格式的文件相比，RDB 文件能夠更快的重啓。
• RDB 對災難恢復很是有用，它是一個緊湊的文件，能夠更快的傳輸到遠程服務器進行 Redis 服務恢復

缺點

• RDB方式數據沒辦法作到實時持久化/秒級持久化，RDB只能保存某個時間間隔的數據，若是在這個期間Redis故障了，就會丟失一段時間的數據。
• RDB方式數據沒辦法作到實時持久化/秒級持久化。由於bgsave每次運 行都要執行fork操做建立子進程，屬於重量級操做，頻繁執行成本太高。

禁用持久化

save ""

AOF持久化

AOF（append only file）持久化：以獨立日誌的方式記錄每次寫命令， 重啓時再從新執行AOF文件中的命令達到恢復數據的目的。AOF的主要做用 是解決了數據持久化的實時性，目前已是Redis持久化的主流方式

AOF的工做流程操做

命令寫入 （append）、文件同步（sync）、文件重寫（rewrite）、重啓加載 （load）。

配置AOF

默認是 no表示關閉 ，yes表示開啓。

• 自動觸發

持久化配置

• always：每條 Redis 操做命令都會寫入磁盤，最多丟失一條數據，但會使得Redis的性能下降，但數據幾乎是全的，基本不會存在丟失數據問題。

• everysec：每秒鐘寫入一次磁盤，最多丟失一秒的數據，對存取數據和性能折中，能夠知足大部分使用場景。

• no：不設置寫入磁盤的規則，根據當前操做系統來決定什麼時候寫入磁盤，通常不採用這種設置。

• 手動觸發

使用bgrewriteaof命令能夠手動觸發aof持久化

隨着時間的推移和數據量變大，aof一直在進行持久化，磁盤日誌愈來愈大，redis重啓速度愈來愈慢，針對這個問題，Redis提供了AOF重寫功能。

Redis中的數據是有必定限量的，最多不超過物理內存大小，不可能說Redis中的數據無限增加，致使aof也無限增加，到必定的時候Redis就會採用緩存淘汰算法LRU自動將以部分數據從內存中給清除。

AOF 重寫配置

• auto-aof-rewrite-min-size：容許 AOF 重寫的最小文件容量，默認是 64m 。
• auto-aof-rewrite-percentage：AOF 文件重寫的大小比例，默認值是 100，表示 100%，也就是隻有當前 AOF 文件，比最後一次（上次）的 AOF 文件大一倍時，纔會啓動 AOF 文件重寫。

AOF 重寫流程

AOF 是存放每條寫命令的，因此會不斷變大，達到必定的時候，AOF作rewrite操做，會從新生成一個新的AOF文件。

優缺點

AOF 優勢

AOF 持久化保存的數據更加完整，AOF 提供了三種保存策略：每次操做保存、每秒鐘保存一次、跟隨系統的持久化策略保存，其中每秒保存一次，從數據的安全性和性能兩方面考慮是一個折中的選擇，也是 AOF 默認的策略，即便發生了意外狀況，最多隻會丟失 1s 鐘的數據；

AOF 採用的是命令追加的寫入方式，因此不會出現文件損壞的問題，即便因爲某些意外緣由，致使了最後操做的持久化數據寫入了一半，也能夠經過 redis-check-aof 工具輕鬆的修復；

AOF 持久化文件，很是容易理解和解析，它是把全部 Redis 鍵值操做命令，以文件的方式存入了磁盤。即便不當心使用 flushall 命令刪除了全部鍵值信息，只要使用 AOF 文件，刪除最後的 flushall 命令，重啓 Redis 便可恢復以前誤刪的數據。

AOF 缺點

對於相同的數據集來講，AOF 文件要大於 RDB 文件；

在 Redis 負載比較高的狀況下，RDB 比 AOF 性能更好；

RDB 使用快照的形式來持久化整個 Redis 數據，而 AOF 只是將每次執行的命令追加到 AOF 文件中，所以從理論上說，RDB 比 AOF 更健壯。

混合持久化

RDB和AOF持久化各有優缺點，RDB會致使一段時間內的數據丟失，AOF文件會愈來愈大，會影響Redis的啓動速度，爲了同時兼顧RDB，AOF的優勢，Redis在4.0版本以後提供了混合持久化方式。

混合持久化

AOF 重寫時會把 Redis 的持久化數據，以 RDB 的格式寫入到 AOF 文件的開頭，以後的數據再以 AOF 的格式化追加的文件的末尾，以下圖所示。

開啓混合

將no改成yes便可

混合持久化優缺點

優勢

混合持久化結合了 RDB 和 AOF 持久化的優勢，開頭爲 RDB 的格式，使得 Redis 能夠更快的啓動，同時結合 AOF 的優勢，有減低了大量數據丟失的風險。

缺點：

AOF 文件中添加了 RDB 格式的內容，會使得 AOF 文件的可讀性會不好，不容易閱讀； 若是開啓混合持久化，就必須使用 Redis 4.0 以及以後版本。

使用混合持久化的時候能夠根據自身業務選擇關閉RDB或者AOF，或者關閉持久化。

關注我

長按二維碼

若是你喜歡這篇文章，喜歡，在看，轉發。