www7777,久久这里只精品国产99热8,国产伦精品一区二区三区免费下载

Redis 持久化是如何做的？一文聊聊 RDB和AOF對比分析

這篇文章我們來介紹Redis高可用相關(guān)的機制。Redis要想實現(xiàn)高可用，主要有以下方面來保證：

數(shù)據(jù)持久化
主從復(fù)制
自動故障恢復(fù)
集群化

這篇文章我們先介紹Redis的高可用保障的基礎(chǔ)：數(shù)據(jù)持久化。因為Redis的主從復(fù)制和自動故障恢復(fù)，都需要依賴Redis持久化相關(guān)的東西。同時，Redis的數(shù)據(jù)持久化也可以用來做數(shù)據(jù)備份，用來保障數(shù)據(jù)的安全性。

Redis是一個內(nèi)存數(shù)據(jù)庫，它的數(shù)據(jù)都保存在內(nèi)存中，如果實例宕機，那么數(shù)據(jù)則全部丟失。如何保證數(shù)據(jù)的完整性和安全性也是提高服務(wù)高可用的重要機制之一。

Redis提供了完善的持久化機制，可以把內(nèi)存中的數(shù)據(jù)持久化到磁盤上，方便我們進行備份數(shù)據(jù)和快速恢復(fù)數(shù)據(jù)。

這篇文章我們就來分析Redis的數(shù)據(jù)持久化是如何實現(xiàn)的？我們經(jīng)常聽的RDB和AOF有什么區(qū)別？以及它們不同的使用場景。

持久化方式

Redis提供的數(shù)據(jù)持久化方式主要有2種：

RDB：產(chǎn)生一個數(shù)據(jù)快照文件
AOF：實時追加命令的日志文件

它們分別對應(yīng)了不同的使用場景，下面我們就來依次分析。

RDB

介紹

RDB全稱 Redis Database Backup file（Redis數(shù)據(jù)備份文件），也被叫做 Redis 數(shù)據(jù)快照。

我們可以通過執(zhí)行save或bgsave命令讓 Redis 在本地生成RDB快照文件，這個RDB文件包含了整個實例接近完整的數(shù)據(jù)內(nèi)容。

Redis 持久化是如何做的？一文聊聊 RDB和AOF對比分析

它的優(yōu)點如下：

RDB文件數(shù)據(jù)是被壓縮寫入的，因此RDB文件的體積要比整個實例內(nèi)存要小
當(dāng)實例宕機恢復(fù)時，加載RDB文件的速度很快，能夠在很短時間內(nèi)迅速恢復(fù)文件中的數(shù)據(jù)

它的缺點也很明顯：

由于是某一時刻的數(shù)據(jù)快照，因此它的數(shù)據(jù)并不全
生成 RDB 文件的代價是比較大的，它會消耗大量的 CPU 和內(nèi)存資源

因此RDB比較適用于以下場景：

主從全量同步數(shù)據(jù)
數(shù)據(jù)庫備份
對于丟失數(shù)據(jù)不敏感的業(yè)務(wù)場景，實例宕機后快速恢復(fù)數(shù)據(jù)

Redis主從全量同步數(shù)據(jù)就是使用RDB文件進行的，我們會在后面的文章詳細講到。

由此可以看出，RDB非常適合做數(shù)據(jù)備份，我們可以定時讓Redis生成RDB文件，然后備份這個快照文件即可。

定時生成RDB

Redis也提供了定時觸發(fā)生成RDB文件的配置項：

# 最近15分鐘內(nèi) 至少產(chǎn)生1次寫入
save 900 1
# 最近5分鐘內(nèi) 至少產(chǎn)生10次寫入
save 300 10
# 最近1分鐘內(nèi) 至少產(chǎn)生10000次寫入
save 60 10000

如果達到以上任意條件，則Redis會自動生成新的RDB文件，降低RDB數(shù)據(jù)內(nèi)容與實例數(shù)據(jù)的差異。

Copy On Write

在Redis上執(zhí)行save和bgsave命令都可以生成RDB文件，但前者是在前臺執(zhí)行的，也就是說在生成RDB文件時，會阻塞整個實例，在RDB未生成之前，任何請求都是無法處理的，對于內(nèi)存很大的實例，生成RDB文件非常耗時，顯然這是我們不能接受的。

所以通常我們會選擇執(zhí)行bgsave讓Redis在后臺生成RDB文件，這樣Redis依舊可以處理客戶端請求，不會阻塞整個實例。

但不是說后臺生成RDB就是沒有代價的，Redis為了實現(xiàn)后臺把內(nèi)存數(shù)據(jù)的快照寫入文件，采用了操作系統(tǒng)提供的Copy On Write技術(shù)，也就是我們熟知的fork系統(tǒng)調(diào)用。

fork 系統(tǒng)調(diào)用會產(chǎn)生一個子進程，它與父進程共享相同的內(nèi)存地址空間，這樣子進程在這一時刻就能擁有與父進程的相同的內(nèi)存數(shù)據(jù)。

雖然子進程與父進程共享同一塊內(nèi)存地址空間，但在fork子進程時，操作系統(tǒng)需要拷貝父進程的內(nèi)存頁表給子進程，如果整個Redis實例內(nèi)存占用很大，那么它的內(nèi)存頁表也會很大，在拷貝時就會比較耗時，同時這個過程會消耗大量的CPU資源。在完成拷貝之前父進程也處于阻塞狀態(tài)，無法處理客戶端請求。

fork執(zhí)行完之后，子進程就可以掃描自身所有的內(nèi)存數(shù)據(jù)，然后把全部數(shù)據(jù)寫入到RDB文件中。

之后父進程依舊處理客戶端的請求，當(dāng)在處理寫命令時，父進程會重新分配新的內(nèi)存地址空間，從操作系統(tǒng)申請新的內(nèi)存使用，不再與子進程共享，這個過程就是Copy On Write（寫實復(fù)制）名字的由來。這樣父子進程的內(nèi)存就會逐漸分離，父進程申請新的內(nèi)存空間并更改內(nèi)存數(shù)據(jù)，子進程的內(nèi)存數(shù)據(jù)不受影響。

由此可以看出，在生成RDB文件時，不僅消耗CPU資源，還有需要占用最多一倍的內(nèi)存空間。

我們在 Redis 執(zhí)行info命令，可以看到fork子進程的耗時，可以通過這個耗時來評估fork時間是否符合預(yù)期。同時我們應(yīng)該保證Redis機器擁有足夠的CPU和內(nèi)存資源，并合理設(shè)置生成RDB的時機。

AOF

介紹

AOF全稱為Append Only File（追加日志文件）。它與RDB不同的是，AOF中記錄的是每一個命令的詳細信息，包括完整的命令類型、參數(shù)等。只要產(chǎn)生寫命令，就會實時寫入到AOF文件中。

Redis 持久化是如何做的？一文聊聊 RDB和AOF對比分析

我們可以通過配置文件開啟AOF：

# 開啟AOF
appendonly yes
# AOF文件名
appendfilename "appendonly.aof"
# 文件刷盤方式
appendfsync everysec

刷盤方式

開啟AOF后，Redis會把每個寫操作的命令記錄到文件并持久化到磁盤中，為了保證數(shù)據(jù)文件的安全性，Redis還提供了文件刷盤的時機：

appendfsync always：每次寫入都刷盤，對性能影響最大，占用磁盤IO比較高，數(shù)據(jù)安全性最高
appendfsync everysec：1秒刷一次盤，對性能影響相對較小，節(jié)點宕機時最多丟失1秒的數(shù)據(jù)
appendfsync no：按照操作系統(tǒng)的機制刷盤，對性能影響最小，數(shù)據(jù)安全性低，節(jié)點宕機丟失數(shù)據(jù)取決于操作系統(tǒng)刷盤機制

以上可以看出AOF相對于RDB的優(yōu)點是，AOF數(shù)據(jù)文件更新比較及時，比RDB保存更完整的數(shù)據(jù)，這樣在數(shù)據(jù)恢復(fù)時能夠恢復(fù)盡量完整的數(shù)據(jù)，降低丟失數(shù)據(jù)的風(fēng)險。

如果同時存在RDB文件和AOF文件，Redis會優(yōu)先使用AOF文件進行數(shù)據(jù)恢復(fù)。

但它的缺點也很易見：

隨著時間增長，AOF文件會越來越大
AOF文件刷盤會增加磁盤IO的負擔(dān)，可能影響Redis的性能（開啟每秒刷盤時）

AOF重寫

針對第一種情況，Redis提供了AOF瘦身的功能，可以設(shè)置在AOF文件很大時，自動觸發(fā)AOF重寫，Redis會掃描整個實例的數(shù)據(jù)，重新生成一個AOF文件達成瘦身的效果。但這個重寫過程也需要消耗大量的CPU資源。

# AOF文件距離上次文件增長超過多少百分比則觸發(fā)重寫
auto-aof-rewrite-percentage 100
# AOF文件體積最小多大以上才觸發(fā)重寫
auto-aof-rewrite-min-size 64mb

由于AOF可以最大可能降低丟失數(shù)據(jù)的風(fēng)險，所以它一般適用于對丟失數(shù)據(jù)很敏感的業(yè)務(wù)場景，例如涉及金錢交易的業(yè)務(wù)。

性能影響

如果AOF的刷盤時機設(shè)置為每次寫入都刷盤，那么會大大降低Redis的寫入性能，因為每次寫命令都需要寫入文件并刷到磁盤中才會返回，當(dāng)寫入量很大時，會增加磁盤IO的負擔(dān)。性能與數(shù)據(jù)安全不能兼得，雖然Redis提供了實時刷盤的機制，但是在真正場景中使用的不多。

通常我們會選擇每秒刷盤這種方式，既能保證良好的寫入性能，在實例宕機時最多丟失1秒的數(shù)據(jù)，做到性能和安全的平衡。