點擊上方“朱小廝的博客”，選擇“設為星標”

后臺回復”加群“加入公眾號專屬技術群

Redis 的讀寫都是在內存中，所以它的性能較高，但在內存中的數(shù)據(jù)會隨著服務器的重啟而丟失，為了保證數(shù)據(jù)不丟失，我們需要將內存中的數(shù)據(jù)存儲到磁盤，以便 Redis 重啟時能夠從磁盤中恢復原有的數(shù)據(jù)，而整個過程就叫做 Redis 持久化。

Redis 持久化也是 Redis 和 Memcached 的主要區(qū)別之一，因為 Memcached 不具備持久化功能。

1.持久化的幾種方式

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

• 快照方式（RDB, Redis DataBase）將某一個時刻的內存數(shù)據(jù)，以二進制的方式寫入磁盤；

• 文件追加方式（AOF, Append Only File），記錄所有的操作命令，并以文本的形式追加到文件中；

• 混合持久化方式，Redis 4.0 之后新增的方式，混合持久化是結合了 RDB 和 AOF 的優(yōu)點，在寫入的時候，先把當前的數(shù)據(jù)以 RDB 的形式寫入文件的開頭，再將后續(xù)的操作命令以 AOF 的格式存入文件，這樣既能保證 Redis 重啟時的速度，又能簡單數(shù)據(jù)丟失的風險。

因為每種持久化方案，都有特定的使用場景，讓我們先從 RDB 持久化說起吧。

2.RDB簡介

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

3.持久化觸發(fā)

RDB 的持久化觸發(fā)方式有兩類：一類是手動觸發(fā)，另一類是自動觸發(fā)。

1）手動觸發(fā)

手動觸發(fā)持久化的操作有兩個：save?和 bgsave?，它們主要區(qū)別體現(xiàn)在：是否阻塞 Redis 主線程的執(zhí)行。

① save?命令

在客戶端中執(zhí)行 save?命令，就會觸發(fā) Redis 的持久化，但同時也是使 Redis 處于阻塞狀態(tài)，直到 RDB?持久化完成，才會響應其他客戶端發(fā)來的命令，所以在生產環(huán)境一定要慎用。

save?命令使用如下：從圖片可以看出，當執(zhí)行完 save?命令之后，持久化文件 dump.rdb?的修改時間就變了，這就表示 save?成功的觸發(fā)了 RDB 持久化。save?命令執(zhí)行流程，如下圖所示：

② bgsave?命令

bgsave（background save）既后臺保存的意思， 它和 save?命令最大的區(qū)別就是 bgsave?會 fork() 一個子進程來執(zhí)行持久化，整個過程中只有在 fork() 子進程時有短暫的阻塞，當子進程被創(chuàng)建之后，Redis 的主進程就可以響應其他客戶端的請求了，相對于整個流程都阻塞的 save?命令來說，顯然 bgsave?命令更適合我們使用。bgsave?命令使用，如下圖所示：

bgsave?執(zhí)行流程，如下圖所示：

2）自動觸發(fā)

說完了 RDB 的手動觸發(fā)方式，下面來看如何自動觸發(fā) RDB 持久化？RDB 自動持久化主要來源于以下幾種情況。

① save m n

save m n?是指在 m 秒內，如果有 n 個鍵發(fā)生改變，則自動觸發(fā)持久化。參數(shù) m 和 n 可以在 Redis 的配置文件中找到，例如， save601?則表明在 60 秒內，至少有一個鍵發(fā)生改變，就會觸發(fā) RDB 持久化。自動觸發(fā)持久化，本質是 Redis 通過判斷，如果滿足設置的觸發(fā)條件，自動執(zhí)行一次 bgsave?命令。注意：當設置多個 save m n 命令時，滿足任意一個條件都會觸發(fā)持久化。例如，我們設置了以下兩個 save m n 命令：

• save 60 10

• save 600 1

當 60s 內如果有 10 次 Redis 鍵值發(fā)生改變，就會觸發(fā)持久化；如果 60s 內 Redis 的鍵值改變次數(shù)少于 10 次，那么 Redis 就會判斷 600s 內，Redis 的鍵值是否至少被修改了一次，如果滿足則會觸發(fā)持久化。

② flushall

flushall?命令用于清空 Redis 數(shù)據(jù)庫，在生產環(huán)境下一定慎用，當 Redis 執(zhí)行了 flushall?命令之后，則會觸發(fā)自動持久化，把 RDB 文件清空。執(zhí)行結果如下圖所示：

③ 主從同步觸發(fā)

在 Redis 主從復制中，當從節(jié)點執(zhí)行全量復制操作時，主節(jié)點會執(zhí)行 bgsave?命令，并將 RDB 文件發(fā)送給從節(jié)點，該過程會自動觸發(fā) Redis 持久化。

4.配置說明

合理的設置 RDB 的配置，可以保障 Redis 高效且穩(wěn)定的運行，下面一起來看 RDB 的配置項都有哪些？

RDB 配置參數(shù)可以在? Redis 的配置文件中找見，具體內容如下：

# RDB 保存的條件

save 9001

save 30010

save 6010000

# bgsave 失敗之后，是否停止持久化數(shù)據(jù)到磁盤，yes 表示停止持久化，no 表示忽略錯誤繼續(xù)寫文件。

stop-writes-on-bgsave-error yes

# RDB 文件壓縮

rdbcompression yes

# 寫入文件和讀取文件時是否開啟 RDB 文件檢查，檢查是否有無損壞，如果在啟動是檢查發(fā)現(xiàn)損壞，則停止啟動。

rdbchecksum yes

# RDB 文件名

dbfilename dump.rdb

# RDB 文件目錄

dir ./

其中比較重要的參數(shù)如下列表：

① save 參數(shù)

它是用來配置觸發(fā) RDB 持久化條件的參數(shù)，滿足保存條件時將會把數(shù)據(jù)持久化到硬盤。默認配置說明如下：

• save 900 1：表示 900 秒內如果至少有 1 個 key 值變化，則把數(shù)據(jù)持久化到硬盤；

• save 300 10：表示 300 秒內如果至少有 10 個 key 值變化，則把數(shù)據(jù)持久化到硬盤；

• save 60 10000：表示 60 秒內如果至少有 10000 個 key 值變化，則把數(shù)據(jù)持久化到硬盤。

② rdbcompression 參數(shù)

它的默認值是 yes?表示開啟 RDB 文件壓縮，Redis 會采用 LZF 算法進行壓縮。如果不想消耗 CPU 性能來進行文件壓縮的話，可以設置為關閉此功能，這樣的缺點是需要更多的磁盤空間來保存文件。

③ rdbchecksum 參數(shù)

它的默認值為 yes?表示寫入文件和讀取文件時是否開啟 RDB 文件檢查，檢查是否有無損壞，如果在啟動是檢查發(fā)現(xiàn)損壞，則停止啟動。

5.配置查詢

Redis 中可以使用命令查詢當前配置參數(shù)。查詢命令的格式為：configgetxxx?，例如，想要獲取 RDB 文件的存儲名稱設置，可以使用 configgetdbfilename?，執(zhí)行效果如下圖所示：

查詢 RDB 的文件目錄，可使用命令 configgetdir?，執(zhí)行效果如下圖所示：

6.配置設置

設置 RDB 的配置，可以通過以下兩種方式：

• 手動修改 Redis 配置文件；

• 使用命令行設置，例如，使用?configsetdir"/usr/data"?就是用于修改 RDB 的存儲目錄。

注意：手動修改 Redis 配置文件的方式是全局生效的，即重啟 Redis 服務器設置參數(shù)也不會丟失，而使用命令修改的方式，在 Redis 重啟之后就會丟失。但手動修改 Redis 配置文件，想要立即生效需要重啟 Redis 服務器，而命令的方式則不需要重啟 Redis 服務器。

小貼士：Redis 的配置文件位于 Redis 安裝目錄的根路徑下，默認名稱為 redis.conf。

7.RDB 文件恢復

當 Redis 服務器啟動時，如果 Redis 根目錄存在 RDB 文件 dump.rdb，Redis 就會自動加載 RDB 文件恢復持久化數(shù)據(jù)。如果根目錄沒有 dump.rdb 文件，請先將 dump.rdb 文件移動到 Redis 的根目錄。

驗證?RDB?文件是否被加載

Redis 在啟動時有日志信息，會顯示是否加載了 RDB 文件，我們執(zhí)行 Redis 啟動命令：src/redis-server redis.conf?，如下圖所示：從日志上可以看出， Redis 服務在啟動時已經正常加載了 RDB 文件。

小貼士：Redis 服務器在載入 RDB 文件期間，會一直處于阻塞狀態(tài)，直到載入工作完成為止。

8.RDB 優(yōu)缺點

1）RDB 優(yōu)點

• RDB 的內容為二進制的數(shù)據(jù)，占用內存更小，更緊湊，更適合做為備份文件；

• RDB 對災難恢復非常有用，它是一個緊湊的文件，可以更快的傳輸?shù)竭h程服務器進行 Redis 服務恢復；

• RDB 可以更大程度的提高 Redis 的運行速度，因為每次持久化時 Redis 主進程都會 fork() 一個子進程，進行數(shù)據(jù)持久化到磁盤，Redis 主進程并不會執(zhí)行磁盤 I/O 等操作；

• 與 AOF 格式的文件相比，RDB 文件可以更快的重啟。

2）RDB 缺點

• 因為 RDB 只能保存某個時間間隔的數(shù)據(jù)，如果中途 Redis 服務被意外終止了，則會丟失一段時間內的 Redis 數(shù)據(jù)；

• RDB 需要經常 fork() 才能使用子進程將其持久化在磁盤上。如果數(shù)據(jù)集很大，fork() 可能很耗時，并且如果數(shù)據(jù)集很大且 CPU 性能不佳，則可能導致 Redis 停止為客戶端服務幾毫秒甚至一秒鐘。

9.禁用持久化

禁用持久化可以提高 Redis 的執(zhí)行效率，如果對數(shù)據(jù)丟失不敏感的情況下，可以在連接客戶端的情況下，執(zhí)行 configsetsave""?命令即可禁用 Redis 的持久化，如下圖所示：

10.小結

通過本文我們可以得知，RDB 持久化分為手動觸發(fā)和自動觸發(fā)兩種方式，它的優(yōu)點是存儲文件小，Redis 啟動時恢復數(shù)據(jù)比較快，缺點是有丟失數(shù)據(jù)的風險。RDB 文件的恢復也很簡單，只需要把 RDB 文件放到 Redis 的根目錄，在 Redis 啟動時就會自動加載并恢復數(shù)據(jù)。

11.思考題

如果 Redis 服務器 CPU 占用過高，可能是什么原因導致的？

歡迎各位讀者在評論區(qū)，寫下自己的答案。

想知道更多？掃描下面的二維碼關注我

怎么加群？：>>>Learn More<<

朕已閱?

總結

以上是生活随笔為你收集整理的Redis持久化的几种方式——RDB深入解析的全部內容，希望文章能夠幫你解決所遇到的問題。

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