• Redis 的持久化是它的一大特性，可以將內(nèi)存中的數(shù)據(jù)寫入到硬盤中
  • 主要分為 RDB 和 AOF 兩種，接下來我們將展開敘述
    • RDB持久化方式能夠在指定的時間間隔能對你的數(shù)據(jù)進行快照存儲
    • AOF持久化方式記錄每次對服務(wù)器寫的操作,當服務(wù)器重啟的時候會重新執(zhí)行這些命令來恢復(fù)原始的數(shù)據(jù)

一、RDB

• RDB持久性以 指定的時間間隔，執(zhí)行數(shù)據(jù)集時間點快照
  • 在指定的時間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫入磁盤，恢復(fù)時將硬盤快照文件讀回到內(nèi)存里
  • 保存?zhèn)浞輹r執(zhí)行的是全量快照 【所有數(shù)據(jù)】
  • RDB 保存的是 dump.rdb 文件
    

?? 1、配置文件的版本區(qū)別

（1）Redis 6.0.16 以下

（2）Redis6.2 以及 Redis 7.0.0

• 那么我們?nèi)绾问褂?RDB 呢？

1.1 自動觸發(fā)

?? 1、進行配置

• 我們可以通過設(shè)置配置文件自動觸發(fā) RDB 的功能

• 首先，我們通過 vim /myredis/redisconfig7.conf 編輯我們拷貝的 redis 配置文件

• 對于 Redis7 中配置RDB觸發(fā)機制的代碼是這樣的 save <seconds> <changes>

  • 此處就設(shè)置為 5s內(nèi)有2次寫操作就觸發(fā) save 5 2
    

• 之后我們需要修改 rdb 文件的保存位置，通過 dir /myredis/dumpfiles 指令完成
  

• 之后在配置文件中修改我們 rdb 文件的名字 dbfilename dump6379.rdb
  > 那么我們?nèi)绾斡|發(fā)備份呢？

• 第一種情況就是達到我們設(shè)置的要求，五秒內(nèi)寫入兩條
  

• 第二種情況：
  

?? 2、如何恢復(fù)呢？

• 在我們重啟 Redis 服務(wù)器登錄客戶端之后，就會去尋找我們的RDB備份文件
• 但是，我們需要知道我們通過 flushdb 清空模擬異常時
  • 執(zhí)行flushdb、flushall命令也會產(chǎn)生 dump.rdb 文件，這樣重啟后數(shù)據(jù)集還是空的，所以沒有任何意義
  • 所以我們需要在模擬前將之前的 rdb 文件改名【防止被覆蓋為空，導(dǎo)致測試失敗】
  • 然后執(zhí)行完 flushdb 命令后，將有數(shù)據(jù)的rdb文件改回原名，這樣重啟Redis就會自動加載這個文件
    
• 我們要注意：物理恢復(fù)一定要把服務(wù)和備份分機隔離
  • 不可以把備份文件dump.rdb和生產(chǎn)redis服務(wù)器放在同一臺機器，必須分開各自存儲，以防生產(chǎn)機物理損壞后備份文件也掛了
    

1.2 手動觸發(fā)

• Redis 提供了save、basave 兩個命令來生成 RDB 文件
• 那么這兩種方式有什么區(qū)別呢？

?? 1、save

• 對于 save 命令，在主程序中執(zhí)行會阻塞當前 redis 服務(wù)器，直到持久化工作完成
  • 就是在執(zhí)行 save 命令期間，Redis 不能處理其他命令 【線上禁止使用】
    
    

?? 2、bgsave

• 對于 bgsave 命令，是Redis默認的手動觸發(fā)RDB功能的指令
  • Redis 會在后臺異步執(zhí)行快照操作，不阻塞快照的同時還可以響應(yīng)客戶端請求。該觸發(fā)方式會 fork 一個子進程，由子進程復(fù)制持久化過程
  • Redis會使用bgsave對當前內(nèi)存中的所有數(shù)據(jù)做快照，這個操作是子進程在后臺完成的，這就允許主進程同時可以修改數(shù)據(jù)

那么 fork 是什么呢？

在Linux程序中，fork()會產(chǎn)生一個和父進程完全相同的子進程，但子進程在此后多會exec系統(tǒng)調(diào)用，出于效率考慮，盡量避免膨脹。

• 我們通過 lastsave 命令可以獲取最后一次成功執(zhí)行快照的時間
  

1.3 優(yōu)缺點

?? 優(yōu)勢

• 適合大規(guī)模的數(shù)據(jù)恢復(fù)
• 按照業(yè)務(wù)定時備份
• 對數(shù)據(jù)完整性和一致性要求不高
• RDB 文件在內(nèi)存中的加載速度要比 AOF 快得多

?? 劣勢

• 在一定間隔時間做一次備份，可能造成快照之間的數(shù)據(jù)丟失
• 內(nèi)存數(shù)據(jù)的全量同步，如果數(shù)據(jù)量太大會導(dǎo)致 I/O 嚴重影響服務(wù)器性能
• RDB 依賴于主進程的 fork，數(shù)據(jù)集很大的情況下可能導(dǎo)致服務(wù)請求的瞬間延遲
• fork 的時候內(nèi)存中的數(shù)據(jù)被克隆了一份，大致2倍的膨脹性，需要考慮

模擬數(shù)據(jù)丟失：

• 正常錄入數(shù)據(jù)：
  
• 使用 kill 命令殺死進程
  
• 重啟服務(wù)器查看結(jié)果
  

1.4 其他配置信息

?? 1、如果我們生成的 dump.rdb 文件出現(xiàn)了問題怎么辦？

• Redis 為我們提供了 redis-check-rdb 文件名 指令可以修復(fù)我們的 RDB 文件
  

?? 2、哪些情況下會觸發(fā) RDB 快照？ 【全局快照寫入硬盤】

• 當前操作滿足了我們在配置文件中默認的快照配置
• 手動執(zhí)行了 save 或 bgsave 命令
• 執(zhí)行了 flushdb 或 flushall 命令 【產(chǎn)生的 dump.rdb 文件里面是空的】
• 主從復(fù)制時，主節(jié)點自動觸發(fā)

?? 3、如果我們不想使用 RDB 的快照功能怎么辦？

• 方式一：在命令行通過 redis-cli config set save "" 指令禁用
• 方式二：通過修改配置文件禁用

?? 4、RBD優(yōu)化配置項詳解？ 【在配置文件中 snapshotting 相關(guān)模塊】

• save <seconds> <changes> 設(shè)置RDB配置文件觸發(fā)規(guī)則
• dbfilename 設(shè)置生成的RDB文件名
• dir 設(shè)置生成的RBD文件存儲路徑
• stop-writes-on-bgsave-error 用于保證數(shù)據(jù)一致性
  • 默認yes；如果配置成no，表示你不在乎數(shù)據(jù)不一致或者有其他的手段發(fā)現(xiàn)和控制這種不一致，那么在快照寫入失敗時，也能確保redis繼續(xù)接受新的寫請求
    
• rdbcompression 用于壓縮我們的RDB文件
  • 默認yes；對于存儲到磁盤中的快照，可以設(shè)置是否進行壓縮存儲。如果是的話，redis會采用LZF算法進行壓縮。如果你不想消耗CPU來進行壓縮的話，可以設(shè)置為關(guān)閉此功能
    
• rdbchecksum 用于檢驗數(shù)據(jù)
  • 默認yes；在存儲快照后，還可以讓redis使用CRC64算法來進行數(shù)據(jù)校驗，但是這樣做會增加大約10%的性能消耗，如果希望獲取到最大的性能提升，可以關(guān)閉此功能
    
• rdb-del-sync-files 用于Redis主從全量同步時,通過RDB文件傳輸實現(xiàn)
  • 在沒有持久性的情況下刪除復(fù)制中使用的RDB文件啟用。默認情況下no，此選項是禁用的 【沒開啟持久化設(shè)置為yes，會移除主從同步的RDB文件】

1.5 總結(jié)

二、AOF

• 是Redis提供的另一種持久化機制
• 以日志的形式記錄每個寫操作，將Redis執(zhí)行過的所有寫指令記錄下來，只許追加文件但不可以改寫文件，Redis 啟動之初會讀取該文件重新構(gòu)建數(shù)據(jù)
  • Redis 重啟會根據(jù)日志文件的內(nèi)容將寫指令從前到后執(zhí)行一次以完成數(shù)據(jù)的恢復(fù)工作
• 默認情況下，Redis 是沒有開啟 AOF 的，需要在Redis的核心配置文件中進行配置
• 生成的是 appendonly.aof 文件
  

2.1 持久化流程

• Client作為命令的來源，會有多個源頭以及源源不斷的請求命令
• 在這些命令到達Redis Server 以后并不是直接寫入AOF文件，會將其這些命令先放入AOF緩存中進行保存。這里的AOF緩沖區(qū)實際上是內(nèi)存中的一片區(qū)域，存在的目的是當這些命令達到一定量以后再寫入磁盤，避免頻繁的磁盤IO操作
• AOF緩沖會根據(jù)AOF緩沖區(qū)同步文件的三種寫回策略將命令寫入磁盤上的AOF文件
• 隨著寫入AOF內(nèi)容的增加為避免文件膨脹，會根據(jù)規(guī)則進行命令的合并(又稱AOF重寫)，從而起到AOF文件壓縮的目的
• 當Redis Server 服務(wù)器重啟的時候會從AOF文件載入數(shù)據(jù)。

2.2 緩沖區(qū)寫回策略

• Always：同步寫回，每個寫命令執(zhí)行完立刻同步地將日志寫回磁盤
• no：操作系統(tǒng)控制寫回，只是把日志寫道 AOF 文件的內(nèi)存緩沖區(qū)，由操作系統(tǒng)決定何時將緩沖區(qū)內(nèi)容寫回磁盤
• everysec：每秒寫回，每個寫命令執(zhí)行完，只是先把日志寫道 AOF 文件的緩沖區(qū)，每隔1s把緩沖區(qū)中的內(nèi)容寫入磁盤

2.3 配置與使用

?? 配置文件說明

• 如何開啟 AOF？

  • 只需修改我們的配置文件，將 appendonly 屬性設(shè)置為 yes
    

• 使用默認回寫策略，即 appendfsync everysec 數(shù)據(jù)先至于 AOF 緩沖區(qū)，每隔1s寫入磁盤

• AOF 文件保存路徑：

  • 在 Redis6 中，與 RDB配置的路徑一致，都是通過 dir 字段設(shè)置
  • 在 Redis7 中， 會在我們 dir 指定的路徑后添加一個 appenddirname 屬性值的目錄
    

• AOF文件保存名稱：

  • 在 Redis6 中，使用配置文件中的 appendfilename 指定文件名

  • 在 Redis7 中，使用了 Multi Part AOF 的設(shè)計

    • base 基本文件 【在我們增量文件達到一定程度，就會重寫到基本文件中】
    • incr 增量文件 【實際記錄我們每次寫操作的文件（增、刪、改）】
    • manifest 清單文件

  
  

?? 正?；謴?fù)

• 啟動：修改默認的 appendonly no 為 yes 【開啟AOF功能】
• 寫操作繼續(xù)，生成 AOF 文件到我們指定的目錄中
  • 恢復(fù)1：重啟 Redis 然后重新加載并執(zhí)行我們 AOF 文件中的寫操作
  • 恢復(fù)2：【是因為我們通過 flushdb + shutdown 的方式退出（重新執(zhí)行aof后還是為空）】

    • 寫入數(shù)據(jù)進 Redis，然后執(zhí)行 flushdb + shutdown 命令

    • 生成了 dump.rdb 和 appenddirname.aof 文件

    • 備份新生成的 aof.bak，然后刪除 dump/aof,嘗試恢復(fù)
      

    • 重啟 Redis 查看結(jié)果
      

    • 停止服務(wù)器，然后將我們有數(shù)據(jù)的 aof 文件改回原名，再次重啟 Redis 查看結(jié)果
      
      

?? 異?；謴?fù)

• 就是我們生成的 AOF 文件存在問題，我們改如何恢復(fù)我們的數(shù)據(jù)？
  • 此處通過修改 AOF 文件模擬錯誤指令vim /myredis/appendonlydir/appendonly.aof.1.incr.aof
    
• 保存后我們嘗試重啟 Redis，發(fā)現(xiàn)無法連接到客戶端
  
• 我們可以采用 Redis 為我們提供的 AOF 文件修復(fù)命令 【重點：不要忘記 --fix 選項】
  
• 再次重啟 Redis 并連接客戶端，發(fā)現(xiàn)數(shù)據(jù)恢復(fù)成功
  

2.4 優(yōu)缺點

?? 優(yōu)勢

• 可以更好的保護數(shù)據(jù)不丟失、性能高、可做緊急恢復(fù)

?? 劣勢

• 針對相同大小的數(shù)據(jù)集，AOF文件的體積要大于RDB文件，恢復(fù)速度也更慢一些
• AOF 運行效率慢于 RDB，每秒同步策略較好，不同步效率和RDB一樣

2.5 重寫機制

• 為什么會產(chǎn)生重寫機制？

  • 由于AOF持久化是Redis不斷將寫命令記錄到 AOF 文件中，隨著Redis不斷的進行，AOF 的文件會越來越大，文件越大，占用服務(wù)器內(nèi)存越大以及 AOF 恢復(fù)要求時間越長
  • 為了解決這個問題，Redis新增了重寫機制，當AOF文件的大小超過所設(shè)定的峰值時，Redis就會自動啟動AOF文件的內(nèi)容壓縮，只保留可以恢復(fù)數(shù)據(jù)的最小指令集或者可以手動使用命令 bgrewriteaof 來重新

• 什么是重寫機制？

  • 啟動 AOF 文件的內(nèi)容壓縮，只保留恢復(fù)數(shù)據(jù)的最小指令集

• 官網(wǎng)給出的相關(guān)默認配置：【同時滿足設(shè)定的多個規(guī)則才會重寫】

  • 我們當前 AOF 文件是上一個 AOF 文件大小的一倍
  • 我們當前的 AOF 文件大小已經(jīng)達到了 64MB
    

• 當然，我們也可以使用 bgrewriteaof 命令手動觸發(fā)重寫功能

接下來我們通過一個案例來演示：

1?? 需求：

2?? 準備工作：

• 刪除之前的 aof、rdb 文件，清除干擾項

• 開啟 AOF 功能 【配置文件 appendonly yes】

• 關(guān)閉 AOF 和 RDB 的混合功能，因為此處我們就是要演示 AOF 重寫功能
  

• 修改重寫峰值【因為只是為了要是效果，文件內(nèi)容沒必要達到64MB】
  

3?? 兩種方式觸發(fā)重寫：

（1）自動觸發(fā)案例

• 在上述配置完成后，重啟 Redis 服務(wù)器，使用 set 指令查看是否可以正常生成我們的三個 AOF 文件
  

• 查看我們的三大文件
  

• 不斷覆蓋我們 k1 鍵對應(yīng)的 value，使我們的 appendonly.aof.1.incr.aof 文件大小達到觸發(fā)重寫大小
  

• 觸發(fā)重寫后我們重新查看增量文件內(nèi)容 >> 只保存了 k1 最后對應(yīng)的 value
  
  （2）手動觸發(fā)案例

• 在客戶端向服務(wù)器發(fā)送 barewriteaof 命令

• 通過我們增量文件大小的改變，我們知道重寫功能成功觸發(fā)了
  

4?? 案例總結(jié)

重寫原理總結(jié)：

• 在重寫開始前，redis會創(chuàng)建一個“重寫子進程”，這個子進程會讀取現(xiàn)有的AOF文件，并將其包含的指令進行分析壓縮并寫入到一個臨時文件中
• 與此同時，主進程會將新接收到的寫指令一邊累積到內(nèi)存緩沖區(qū)中，一邊繼續(xù)寫入到原有的AOF文件中，這樣做是保證原有的AOF文件的可用性，避免在重寫過程中出現(xiàn)意外
• 當“重寫子進程”完成重寫工作后，它會給父進程發(fā)一個信號，父進程收到信號后就會將內(nèi)存中緩存的寫指令追加到新AOF文件中
• 當追加結(jié)束后，redis就會用新AOF文件來代替舊AOF文件，之后再有新的寫指令，就都會追加到新的AOF文件中
• 重寫aof文件的操作，并沒有讀取舊的aof文件，而是將整個內(nèi)存中的數(shù)據(jù)庫內(nèi)容用命令的方式重寫了一個新的aof文件，這點和快照有點類似

配置文件項說明：

三、混合持久化

• 就是開啟 AOF 和 RDB 混合功能實現(xiàn)持久化
  • RDB持久化方式能夠在指定的時間間隔能對你的數(shù)據(jù)進行快照存儲
  • AOF持久化方式記錄每次對服務(wù)器寫的操作，當服務(wù)器重啟的時候會重新執(zhí)行這些命令來恢復(fù)原始的數(shù)據(jù)，AOF命令以redis協(xié)議追加保存每次寫的操作到文件末尾.
    
• 那么我們開啟兩種功能，數(shù)據(jù)恢復(fù)和加載流程是怎樣的呢？
  • 實際重啟的時候只會加載 AOF 文件，不會加載 RDB 文件
    • 因為 AOF 文件可以保證數(shù)據(jù)更完整
    • 而 RDB 文件更適合用于做備份
      

?? 總結(jié)：

• 結(jié)合了RDB和 AOF 的優(yōu)點，既能快速加載又能避免丟失過多的數(shù)據(jù)

• 如何開啟混合功能呢？

  • 在配置文件中，做如下設(shè)置 `aof-use-rdb-preamble yes

• RDB 鏡像做全量持久化， AOF 做增量持久化

  • 先使用RDB進行快照存儲，然后使用AOF持久化記錄所有的寫操作，當重寫策略滿足或手動觸發(fā)重寫的時候，將最新的數(shù)據(jù)存儲為新的RDB記錄
  • 重啟服務(wù)的時候會從RDB和AOF兩部分恢復(fù)數(shù)據(jù)，既保證了數(shù)據(jù)完整性，又提高了恢復(fù)數(shù)據(jù)的性能
  • 混合持久化方式產(chǎn)生的文件一部分是RDB格式，一部分是AOF格式 【AOF包括了RDB頭部+AOF混寫】
    

四、純緩存模式

• 什么是純緩存模式呢？

  • 就是關(guān)閉 RDB 和 AOF 的功能，Redis 只用來做緩存，無需實現(xiàn)持久化

• 那么我們?nèi)绾侮P(guān)閉 RDB 和 AOF 功能呢？

  • 都可以在配置文件中設(shè)置
    • save "" 就可以關(guān)閉 RDB 的功能
    • appendonly no 就可以關(guān)閉 AOF 的功能

• 盡管我們關(guān)閉了持久化的功能（通過配置文件的方式），但是我們還可以生成RDB、AOF文件：文章來源地址http://www.zghlxwxcb.cn/news/detail-407368.html

  • 我們可以通過 save、bgsave 指令生成 RDB 文件
  • 我們可以通過 bgrewriteaof 指令生成 AOF 文件

到了這里，關(guān)于【Redis7學(xué)習(xí)日記】—— Redis持久化的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！