從這篇文章開始，我們來介紹Redis高可用相關的機制。Redis要想實現高可用，主要有以下方面來保證：

• 數據持久化
• 主從復制
• 自動故障恢復

• 集群化

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

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

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

這篇文章我們就來分析Redis的數據持久化是如何實現的？我們經常聽的RDB和AOF有什么區別？以及它們不同的使用場景。

數據持久化

Redis提供的數據持久化方式主要有2種：

• RDB：產生一個數據快照文件
• AOF：實時追加命令的日志文件

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

一、RDB

1、介紹

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

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

它的優點如下：

• RDB文件數據是被壓縮寫入的，因此RDB文件的體積要比整個實例內存要小

• 當實例宕機恢復時，加載RDB文件的速度很快，能夠在很短時間內迅速恢復文件中的數據

它的缺點也很明顯：

• 由于是某一時刻的數據快照，因此它的數據并不全

• 生成RDB文件的代價是比較大的，它會消耗大量的CPU和內存資源

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

• 主從全量同步數據
• 數據庫備份

• 對于丟失數據不敏感的業務場景，實例宕機后快速恢復數據

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

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

2、定時生成RDB

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

#?最近15分鐘內?至少產生1次寫入
save?900?1
#?最近5分鐘內?至少產生10次寫入
save?300?10
#?最近1分鐘內?至少產生10000次寫入
save?60?10000

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

3、Copy On Write

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

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

但不是說后臺生成RDB就是沒有代價的，Redis為了實現后臺把內存數據的快照寫入文件，采用了操作系統提供的Copy On Write技術，也就是我們熟知的fork系統調用。

fork系統調用會產生一個子進程，它與父進程共享相同的內存地址空間，這樣子進程在這一時刻就能擁有與父進程的相同的內存數據。

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

fork執行完之后，子進程就可以掃描自身所有的內存數據，然后把全部數據寫入到RDB文件中。

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

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

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

二、AOF

1、介紹

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

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

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

2、刷盤方式

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

• appendfsync always：每次寫入都刷盤，對性能影響最大，占用磁盤IO比較高，數據安全性最高
• appendfsync everysec：1秒刷一次盤，對性能影響相對較小，節點宕機時最多丟失1秒的數據

• appendfsync no：按照操作系統的機制刷盤，對性能影響最小，數據安全性低，節點宕機丟失數據取決于操作系統刷盤機制

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

如果同時存在RDB文件和AOF文件，Redis會優先使用AOF文件進行數據恢復。

但它的缺點也很易見：

• 隨著時間增長，AOF文件會越來越大

• AOF文件刷盤會增加磁盤IO的負擔，可能影響Redis的性能(開啟每秒刷盤時)

3、AOF重寫

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

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

由于AOF可以最大可能降低丟失數據的風險，所以它一般適用于對丟失數據很敏感的業務場景，例如涉及金錢交易的業務。

4、性能影響

如果AOF的刷盤時機設置為每次寫入都刷盤，那么會大大降低Redis的寫入性能，因為每次寫命令都需要寫入文件并刷到磁盤中才會返回，當寫入量很大時，會增加磁盤IO的負擔。

性能與數據安全不能兼得，雖然Redis提供了實時刷盤的機制，但是在真正場景中使用的不多。

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

總結

我們對RDB和AOF的總結如下表。

#RDBAOF

持久化方式	生成某一時刻的數據快照文件	實時記錄每一個寫命令到文件
數據完整性	不完整，取決于備份周期	相對完整性高，取決于文件刷盤方式
文件大小	壓縮二進制寫入，文件較小	原始的操作命令，文件大
宕機恢復時間	快	慢
恢復優先級	低	高
持久化代價	高，消耗大量CPU和內存	低，只占用磁盤IO資源
使用場景	數據備份、主從全量復制、對丟數據不敏感的業務場景快速數據恢復	對于丟失數據敏感的場景，例如涉及金錢交易相關的業務

我們需要針對不同的業務場景選擇合適的持久化方式，也可以根據RDB和AOF的優點配合使用，保證Redis數據的安全性，又可以兼顧它的性能。

作者：Kaito

kaito-kidd.com/2020/06/29/redis-persistence-rdb-aof/

往期精選

Spring Boot 集成 Quartz 實現定時任務的動態創建、啟動、暫停、恢復、刪除等操作

IntelliJ IDEA 15款 神級超級牛逼插件推薦(自用，真的超級牛逼)

2020年最新 JDK 15 版本新特性介紹，突然感覺 JDK 8 不香了！

盤點那些最常用的 Linux 命令，都應該記熟！

華為鴻蒙 OS 嘗鮮，跑了個 “hello world”！跑通后，我特么開始懷疑人生...

最全面 Mybatis 框架核心配置文件使用總結，值得收藏

如何設計類似 QQ、微信等第三方賬號登錄 ？(附表結構)

一款免費數據庫管理工具，比 Navicat 更好有用，功能更強大，強烈推薦！

Redis如何實現故障自動恢復？淺析哨兵的工作原理

為什么 MySQL 不推薦使用 uuid 或者雪花 id 作為主鍵？

點個贊，就知道你“在看”！

總結

以上是生活随笔為你收集整理的quartz持久化是指_面试必问：Redis 持久化是如何做的？RDB 和 AOF 对比分析的全部內容，希望文章能夠幫你解決所遇到的問題。

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