1.概述

Redis是一個基于內(nèi)存的數(shù)據(jù)庫，這意味著其主要數(shù)據(jù)存儲和操作均在內(nèi)存中進行。這種設(shè)計使得Redis能夠提供極快的讀寫速度(通常達到微秒級別)，適用于高性能場景，如緩存

• 然而，由于內(nèi)存的易失性(斷電后數(shù)據(jù)會丟失)，Redis提供了持久化機制：將內(nèi)存中的數(shù)據(jù)保存到磁盤中，確保數(shù)據(jù)在Redis服務(wù)重啟或崩潰后能夠恢復(fù)。通過持久化，可以避免數(shù)據(jù)丟失，提高數(shù)據(jù)的可靠性
• Redis提供兩種持久化方式
  • RDB(Redis Database)：生成數(shù)據(jù)集的快照實現(xiàn)持久化
  • AOF(Append Only File)：記錄所有寫操作命令，以追加方式寫入文件

2.RDB

RDB指的是Redis的一種持久化機制，其核心是生成Redis數(shù)據(jù)在某個時間點的快照

2.1 快照原理

由于Redis是單線程應(yīng)用程序，在線上環(huán)境時，不僅要處理來自客戶端的請求，還要執(zhí)行內(nèi)存快照操作(進行文件IO)。單線程同時處理客戶端請求和文件IO時會嚴重降低服務(wù)器性能，甚至阻塞客戶端請求。因此，Redis使用 fork 和 寫實拷貝(Copy On Write) 機制來實現(xiàn)快照持久化

fork

        Redis在進行RDB持久化時會調(diào)用fork函數(shù)來創(chuàng)建一個子進程負責完成，父進程則繼續(xù)處理客戶端請求。子進程在創(chuàng)建之初和父進程共享同一數(shù)據(jù)段

        Linux操作系統(tǒng)的內(nèi)存空間被分為很多種片段，每個片段又被分為很多個頁面，每個頁面4KB

寫實拷貝

        當父進程對數(shù)據(jù)段中的某一數(shù)據(jù)頁面進行修改操作時，Linux操作系統(tǒng)會將該數(shù)據(jù)頁面復(fù)制一份分離出來，然后對該頁面進行修改，最后父進程指向指向修改后的頁面。隨著被修改的頁面越來越多，內(nèi)存空間不斷膨脹，最多達到原來的兩倍
        從子進程被創(chuàng)建出來的那一刻起，直至拷貝結(jié)束，子進程始終指向原始的數(shù)據(jù)段且所有原數(shù)據(jù)段不會被修改。所以，在整個拷貝過程中 RDB快照 = 子進程看到的所有數(shù)據(jù)頁面的瞬間狀態(tài)集合

        拷貝完成后，子進程會被銷毀，同時沒有指針指向的數(shù)據(jù)頁面也會被銷毀

2.2 觸發(fā)機制

Redis RDB的觸發(fā)機制分為自動觸發(fā)和手動觸發(fā)兩種方式

• 自動觸發(fā)
  • 在redis.conf中通過save指令配置閾值。當在指定時間內(nèi)發(fā)生足夠數(shù)量的鍵修改時自動觸發(fā)bgsave
  • 正常關(guān)閉Redis

    # 默認執(zhí)行save(阻塞式)
    > shutdown
    # 或
    > shutdown save
    
    # 觸發(fā)流程：
    1. 停止接受新連接
    2. 執(zhí)行save(不是bgsave)
    3. 保存完成后退出
    

• 手動觸發(fā)
  • save命令：同步阻塞式觸發(fā)，執(zhí)行期間Redis服務(wù)器不處理任何請求，直到RDB文件創(chuàng)建完成(不推薦)
  • bgsave命令：異步非阻塞式觸發(fā)，Redis會fork一個子進程執(zhí)行持久化操作，主進程繼續(xù)處理請求

2.3 文件處理

        RDB文件保存在dir配置指定的目錄下(默認/var/lib/redis)，文件名通過dbfilename配置指定(默認dump.sql)
        在RDB備份過程中，fork出的子進程會將內(nèi)存數(shù)據(jù)寫入臨時文件，臨時文件默認命名規(guī)則為temp-< pid >.rdb，其中< pid >是子進程的進程ID。當子進程完成RDB文件寫入后，Redis會用原子性的rename操作將臨時文件重命名為正式RDB文件并刪除原文件

2.4 優(yōu)缺點

優(yōu)點

• 恢復(fù)速度快：RDB是數(shù)據(jù)的二進制快照，恢復(fù)時直接加載到內(nèi)存
• 備份時對服務(wù)影響小：使用bgsave命令時，Redis通過fork子進程在后臺保存數(shù)據(jù)，主進程可以繼續(xù)處理客戶端請求，幾乎無阻塞
• 存儲高效：RDB 文件使用二進制格式并支持LZF壓縮

缺點

• 非實時一致性：RDB保存的是某個瞬間的快照，如果保存過程中有大量寫入，快照可能不反映完全一致的業(yè)務(wù)狀態(tài)
• 可能丟失更多數(shù)據(jù)：如果Redis意外宕機，從上一次RDB保存到宕機之間的所有數(shù)據(jù)修改都會丟失

3.AOF

AOF持久化通過將Redis服務(wù)器接收到的每個寫命令追加到文件末尾來實現(xiàn)

# 開啟AOF
appendonly yes

3.1 工作流程

• 命令追加：當Redis執(zhí)行寫命令時，該命令會以Redis協(xié)議格式追加到內(nèi)存中的AOF緩沖區(qū)(aof_buf)。緩沖區(qū)會根據(jù)配置策略決定何時將內(nèi)容同步到磁盤
• 文件寫入與同步：AOF緩沖區(qū)內(nèi)容會被寫入到AOF文件，具體同步到磁盤的時機由appendfsync參數(shù)控制：
  • always：每次寫命令后同步，數(shù)據(jù)安全性最高但性能影響較大
  • everysec：每秒同步一次，平衡性能與安全性(默認配置)
  • no：由操作系統(tǒng)決定同步時機，性能最好但可能丟失較多數(shù)據(jù)

3.2 重寫機制

作用：解決AOF文件不斷增長導(dǎo)致的存儲空間占用和恢復(fù)效率問題。通過重寫，可以生成一個更緊湊的AOF文件，僅包含重建當前數(shù)據(jù)集所需的最小命令集合(例如，對同一個鍵多次修改會記錄多條命令，而重寫機制會合并這些操作，僅保留最終狀態(tài)的命令)

        父進程通過fork創(chuàng)建一個子進程來完成AOF文件的重寫，確保主進程繼續(xù)處理客戶端請求。子進程會讀取當前數(shù)據(jù)庫的快照數(shù)據(jù)，并將其轉(zhuǎn)換為一系列Redis命令寫入新的臨時AOF文件

        在重寫過程中，主進程會將新接收到的寫命令同時寫入現(xiàn)有的AOF 緩沖區(qū)aof_buf(保證原有 AOF 文件正常更新)和AOF重寫緩沖區(qū)aof_rewrite_buf(保證新命令不會丟失)

        當子進程完成重寫后，會通知主進程。主進程會將 AOF 重寫緩沖區(qū)中的命令追加到新生成的臨時 AOF 文件中，最后原子性地替換舊文件

        在Redis7.0.15版本，AOF文件保存在dir + appenddirname配置指定的目錄下(默認/var/lib/redis/appendonlydir)。文件前綴名通過appendfilename配置指定(默認appendonly)

• appendonly.aof.1.base.rdb：作為Redis AOF(Append-Only File)持久化機制的基準文件，存儲某一時刻數(shù)據(jù)庫的完整快照。格式為RDB，體積較小且加載速度快，用于重建數(shù)據(jù)的基礎(chǔ)狀態(tài)
• appendonly.aof.1.incr.aof和appendonly.aof.2.incr.aof：記錄基準文件生成后的增量寫操作命令，以文本形式追加存儲。多個增量文件按操作順序編號(如.1.incr.aof、.2.incr.aof)，Redis 重啟時會按順序重放這些命令以恢復(fù)最新數(shù)據(jù)
• appendonly.aof.manifest：描述AOF文件的組成和順序的清單文件

4.混合持久化

        Redis 混合持久化結(jié)合了 RDB(快照)和 AOF(日志)兩種持久化方式的優(yōu)勢，在保證數(shù)據(jù)安全性的同時兼顧性能

# 開啟混合持久化
aof-use-rdb-preamble yes

• 基礎(chǔ)RDB文件優(yōu)先加載：appendonly.aof.1.base.rdb作為全量快照數(shù)據(jù)文件，會優(yōu)先被加載。該文件包含某一時間點的完整數(shù)據(jù)快照，恢復(fù)時作為基準數(shù)據(jù)集
• 增量AOF文件后續(xù)應(yīng)用：appendonly.aof.1.incr.aof作為增量操作日志，在基礎(chǔ)RDB加載完成后被重放。該文件記錄自 RDB 快照生成后的所有寫操作，用于恢復(fù)最新數(shù)據(jù)狀態(tài)

到此這篇關(guān)于Redis 7持久化RDB和AOF的原理機制講解（圖文教程）的文章就介紹到這了,更多相關(guān)Redis持久化RDB和AOF內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論