[[425943]]

本文轉(zhuǎn)載自微信公眾號「小菜良記」，作者蔡不菜丶。轉(zhuǎn)載本文請聯(lián)系小菜良記公眾號。

大家好，我是小菜。一個希望能夠成為 吹著牛X談架構 的男人!如果你也想成為我想成為的人，不然點個關注做個伴，讓小菜不再孤單!

最近在面試的路上愈走愈遠了，Redis肯定是一個熱門面試方向。像有幾種數(shù)據(jù)結(jié)構?如何實現(xiàn)延遲隊列?淘汰機制是怎么樣的?都快問到麻木，這些問題還常繞腦梁。那我們這篇就舉一個比較常見且難度適中的面試題來聊聊。Redis 的持久化策略是怎么樣的?

開局問個問題，相信被問到 Redis 持久化 的同學肯定不在少數(shù)，答對的同學肯定也不在少數(shù)，有些小伙伴說到 Redis持久化 肯定張口就來，畢竟也就 AOF 和 RDB 兩個概念，只要你準備了面試，就不會被問的太慘。但是你是真的懂還是只是為了應付面試而去應付記憶?你知道 AOF 和 RDB 兩個詞是什么單詞的縮寫嗎?你落地實施過嗎?你真以為面試官聽不出來你是背題還是實操嗎?如果 4 個問題你中了一半，那不妨往下看看，也許會有些收獲，起碼答面試題的時候心中有小菜~!

Redis 持久化

什么是Redis持久化?

咱們先別記得往解決方向前行，先明白這道題的意思。

持久化 就是要讓數(shù)據(jù)永久的保存下去。那什么是 Redis 持久化 ?那就是把Redis保存在內(nèi)存的數(shù)據(jù)寫到磁盤中，防止服務宕機了內(nèi)存數(shù)據(jù)丟失問題。那有些小伙伴就說了，那磁盤損壞了，數(shù)據(jù)怎么持久化?就算多點備份能解決磁盤損壞問題，那如果來個多點丟失怎么整?停住停住，咱們這篇講的是Redis內(nèi)存數(shù)據(jù)->磁盤的持久化問題，可別指望靠這個問題跟面試官扯半個小時~!

咱們這篇從幾個點來說明 Redis持久化 問題。

也就三點大的方向，三步走戰(zhàn)略解決你的持久化問題。

一、RDB

先來解決開局的問題之一，RDB 是什么單詞的全稱。RDB(Redis Database Backup file)--- Redis 數(shù)據(jù)備份文件，也稱為 Redis 數(shù)據(jù)快照。

這個玩意就是用來將內(nèi)存中的所有數(shù)據(jù)都記錄到磁盤中，當 Redis 實例故障重啟后，從磁盤讀取快照文件，從而恢復數(shù)據(jù)。內(nèi)心狂喜，看來學的第一個概念就可以解決 Redis 持久化問題~

在學 RDB 之前，我們先明白兩個核心概念 fork 和 cow，下面我們會解釋，這里先賣個關子。

RDB 是 Redis 中默認的持久化機制，按照一定的時間將內(nèi)存中的數(shù)據(jù)以快照的方式保存到磁盤中，它會產(chǎn)生一個特殊類型的文件 .rdb 數(shù)據(jù)文件，同時可以通過配置文件中的 save 參數(shù)來定義快照的周期.

我們從配置文件中的兩個配置參數(shù)入手，首先是 save 配置。

這個指令是由 Redis 主進程來執(zhí)行RDB，會阻塞所有命令

我們在配置文件中找到有關于 sava 的配置

dbfilename dump.rdb 

該配置項的作用便是用來定義 rdb 文件名(需要注意該名稱不能定義為路徑，只能定義為文件名稱)

當我們執(zhí)行完 save 命令后，便可在 redis 文件夾中看到一個 dump.rdb 文件

save <seconds> <changes> 

該配置項的作用是用來定義多長時間內(nèi)發(fā)生多少次變化便會執(zhí)行 bgsave，如果是 save "" 則表示禁用 RDB。

我們接下來打開 save 配置進行測試

dbfilename dump-test.rdb  # 文件名為 dump-test.rdb 
save 3600 1  # 在 3600 秒內(nèi)發(fā)生一次更改，便會執(zhí)行 bgsave 

我們通過 redis-cli 進入操作

然后我們退出后便可在當前目錄下看到剛剛生成的 dump-test.rdb 文件

說明我們配置是生效的，接著我們直接重啟 Redis ，看是否還存在我們剛剛保存的數(shù)據(jù)

看到我們的數(shù)據(jù)，就說明 redis 持久化成功了。然后我們把剛剛生成的 dump-test.rdb 文件刪除后重啟 redis

這可以說明Redis 啟動時是靠 .rdb 來恢復文件數(shù)據(jù)的。那我們上面一直說到的 bgsave，那 bgsave 又是如何執(zhí)行的呢?

我們在前面有說過兩個概念 fork 和 cow，不知道是否還有印象，這兩個概念便是關鍵~!

bgsave 開始的時候會 fork 主進程得到一個新的子進程，而 子進程 是 共享 主進程的內(nèi)存數(shù)據(jù)的。子進程會將數(shù)據(jù)寫到磁盤上的一個臨時的 .rdb 文件中，當子進程寫完臨時文件后，會將原來的 .rdb文件替換掉。這個就是 fork 的核心，那什么是 cow 呢?cow 全稱 copy-on-write 技術，當主進程執(zhí)行讀操作的時候是訪問共享內(nèi)存的，而主進程執(zhí)行寫操作的時候，則會拷貝一份數(shù)據(jù)，執(zhí)行寫操作。

具體流程如下：

這種持久化方式有什么優(yōu)點呢?

• 方便持久化，只有一個 dump.rdb 文件
• 容災性好，可以將文件保存到安全的磁盤中
• 性能最大化，fork 子進程來完成寫操作，讓主進程繼續(xù)處理命令，將 IO 最大化，保證 Redis 的高性能

缺點也是有的：

• 數(shù)據(jù)安全性低，RDB 是間隔一段時間來持久化 (save) ，如果持久化期間 Redis 發(fā)生故障，那么就會造成數(shù)據(jù)丟失，所以這種方式適用于數(shù)據(jù)要求不是很嚴謹?shù)那闆r下使用
• 保存時間長，如果數(shù)據(jù)量很大，保存快照的時間就會很長，會占用磁盤空間

優(yōu)劣均沾，斟酌使用

二、AOF

AOF 全稱 Append Only File (追加文件)。作用便是 Redis 處理的每一個寫命令都會記錄在 AOF 文件中，可以看做是命令日志文件。

該功能默認是關閉的，我們可以在 redis.conf 文件中查看有關于 AOF 相關的配置項

appendonly yes   # 開啟 AOF 日志記錄功能，默認是關閉的 

appendfilename "appendonly.aof"  # AOF 文件的名稱 

以上兩個配置項便是用來開啟 AOF 日志記錄，那么還有個額外的配置項也需要了解

appendfsync everysec # AOF 命令記錄的頻率 

該配置項有三個可選值

有了解 Mysql 中 relay log 日志的同學，就不會對這種模型很陌生。

原理：它是將寫命令追加到 AOF 文件的末尾，使用 AOF 持久化需要設置同步選項，從而確保寫命令同步到磁盤文件上的時機，這是因為對文件進行寫入并不會馬上將內(nèi)存同步到磁盤上，而是先存儲到緩存區(qū)中，然后由操作系統(tǒng)決定什么時候同步到磁盤。

我們開啟 AOF 記錄功能查看下：

可以看出我們的每一個操作都已經(jīng)記錄到 AOF 文件中，我們這邊通過重啟 Redis 也一樣能獲取到剛剛存儲的數(shù)據(jù)，說明持久化是有生效的~

我們看到上面的 AOF 記錄文件是不是覺得很規(guī)整?但是在線上環(huán)境中越規(guī)整反而不好，因為這文件主要是給機器看的，而不是跟我們看的，因此我們最好能夠進行壓縮。

為了解決AOF文件體積不斷增大的問題，用戶可以向Redis發(fā)送 bgrewriteaof命令，這個命令會通過 通過移除AOF文件中的冗余命令 來重寫(rewrite)AOF文件，使AOF文件的體積變得盡可能地小。bgrewriteaof的工作原理和 bgsave 創(chuàng)建快照的工作原理非常相似：Redis會創(chuàng)建一個子進程，然后由子進程負責對AOF文件進行重寫。因為AOF文件重寫也需要用到子進程，所以快照持久化因為創(chuàng)建子進程而導致的性能問題和內(nèi)存占用問題，在AOF持久化中也同樣存在。

既然存在手動觸發(fā)壓縮，那也存在自動觸發(fā)壓縮，這就得說到配置文件中的兩個配置項

auto-aof-rewrite-percentage 100 
auto-aof-rewrite-min-size 64mb 

該配置項的意思為當AOF文件的體積大于64MB，并且AOF文件的體積比上一次重寫之后的體積大了至少一倍(100%)的時候，Redis將執(zhí)行bgrewriteaof命令。

總結(jié)下，它的優(yōu)點如下：

• 數(shù)據(jù)安全。AOF 持久化可以配置 appendfsync 屬性中的 always，每進行一次寫命令操作就會記錄到 AOF 文件中一次
• 一致性。通過 append 模型寫文件，即使中途服務器宕機，也可以通過 redis-check-aof 工具來解決數(shù)據(jù)一致性問題

缺點如下：

• AOF 文件比 RDB 文件大，而且恢復速度慢
• 數(shù)據(jù)集大的時候比 RDB 文件啟動效率低

同樣是優(yōu)劣均沾，斟酌使用

三、兩者區(qū)別

分別介紹了兩者，我們回顧一下兩者有什么區(qū)別?

看完上面后，想必對兩種持久化機制都有一定的了解了。兩者都有優(yōu)劣勢，那我們該如何選擇?這里給出幾點意見~

如果可以忍受一小段時間內(nèi)的數(shù)據(jù)丟失，可以使用 RDB 機制，定時生成 RDB 快照， 并且 RDB 恢復數(shù)據(jù)集的速度也要比 AOF 恢復的速度要快

但是如果單單使用 RDB 機制，可能導致丟失很多數(shù)據(jù)，因此我們需要綜合使用 AOF 和 RDB 兩種持久化機制，用 AOF 來保證數(shù)據(jù)不丟失，作為數(shù)據(jù)恢復的第一選擇;用 RDB 來做不同程度的冷備份，在 AOF 文件都丟失或損壞不可用的情況下，可以使用 RDB 來進行快速的數(shù)據(jù)恢復

我們可以利用 RDB 來快速恢復數(shù)據(jù)，并用 AOF 來補全數(shù)據(jù)

我們到這里就講述了 Redis 持久化機制的配置，通過這篇文章的學習，我相信到時候面試的時候遇到這個問題也不至于那么手足無措~!

不要空談，不要貪懶，和小菜一起做個吹著牛X做架構的程序猿吧~點個關注做個伴，讓小菜不再孤單。咱們下文見!