Redis基礎系列-持久化
文章目錄
- Redis基礎系列-持久化
- 1. 什么是持久化
- 2. 為什么要持久化
- 3. 持久化的兩種方式
- 3.1 持久化方式1：RDB(redis默認持久化方式)
- 3.11 配置步驟-自動觸發
- 3.12 配置步驟-手動觸發
- 3.12 優點
- 3.13 缺點
- 3.14 檢查和修復RDB快照文件
- 3.15 哪些情況會觸發RDB快照
- 3.16 如何禁用快照
- 3.17 RDB優化配置項詳解
- 3.2 持久化方式2：AOF
- 3.2.1 AOF持久化工作流程
- 3.2.2 三種寫回策略
- 3.2.3 AOF配置說明
- 3.2.4 AOF文件說明
- 3.2.5 AOF恢復
- 3.2.6 AOF文件修復
- 3.2.7 AOF重寫機制
- 3.2.8 總結
- 3.3 持久化方式3：混合模式RDB+AOF
- 3.3.1 混合模式介紹
- 3.3.2 開啟混合方式設置
- 3.3.3 數據的加載流程
- 3.4 純緩存模式
- 4. 參考和感謝
1. 什么是持久化
內存中的數據保存到磁盤中
2. 為什么要持久化
Redis持久化可以將內存中的數據保存到硬盤上，保證Redis的數據持久性和可靠性，以避免數據在異常情況下丟失和損壞。持久化是保證Redis應用安全的重要手段。
3. 持久化的兩種方式
redis持久化官網介紹
3.1 持久化方式1：RDB(redis默認持久化方式)
RDB（Redis DataBase）模式是Redis的默認持久化模式。它會將Redis在某個時間點上的數據生成一個快照，并將快照以二進制形式保存在磁盤上。RDB模式的優點在于快速且緊湊，適合用于備份和恢復數據。然而，由于定期生成快照的特性，可能會導致在兩次快照之間的數據丟失。
適用場景： 對數據的實時性要求不高，可以接受一定程度的數據丟失，同時對于需要頻繁備份和恢復數據的場景。
3.11 配置步驟-自動觸發
- 操作步驟：
1.修改5秒2次變更
save 5 2
2.修改快照文件保存路徑（需優先創建：dumpfiles目錄）
dir /myredis/dumpfiles
3.修改快照名稱
dbfilename dump6379.rdb
- 重啟redis驗證配置是否成功(略)
127.0.0.1:6379> config get save
1) "save"
2) "5 2"
127.0.0.1:6379> config get dir
1) "dir"
2) "/myredis/dumpfiles"
127.0.0.1:6379> config get dbfilename
1) "dbfilename"
2) "dump6379.rdb"
127.0.0.1:6379>
- 觸發配置
// 變更兩次，查看是否會生產快照文件
127.0.0.1:6379> keys *
(empty array)
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379>
- 備份恢復
- redis 執行
flushall也會產生dump文件，不過是空的 - redis 執行
shutdown也會產生dump文件，不過是空的 - redis 直接重啟就會加載備份的快照文件
- redis 執行
3.12 配置步驟-手動觸發
- save命令
在主程序中執行會阻塞當前redis服務器，直到持久化工作完成執行save命令期間，Redis不能處理其他命令，線上禁止使用
- bgsave(Background Save)命令(默認)
Redis會使用bgsave對當前內存中的所有數據做快照這個操作是子進程在后臺完成的，這就允許主進程同時可以修改數據
可以通過lastsave命令獲取最后一次成功執行快照的時間
127.0.0.1:6379> lastsave
(integer) 1701683772
127.0.0.1:6379>
[root@Docker110]# date -d @1701683772
2023年 12月 04日 星期一 17:56:12 CST
3.12 優點
- 適合大規模的數據恢復按照業務定時備份
- 對數據完整性和一致性要求不高
- RDB文件在內存中的加載速度要比 AOF 快得多
3.13 缺點
- 在一定間隔時間做一次備份，所以如果redis章外down掉的話，就會丟失從當前至最近一次快照期間的數據，快照之間的數據會丟失
- 內存數據的全量同步，如果數據量太大會導致I/O嚴重影響服務器性能RDB依賴于主進程的fork，在更大的數據集中，這可能會導致服務請求的瞬間延遲。fork的時候內存中的數據被克隆了一分，大致2倍的膨脹性，需要考慮
3.14 檢查和修復RDB快照文件
redis-check-rdb /myredis/dumpfiles/dump6379.rdb
3.15 哪些情況會觸發RDB快照
- 配置文件中默認的快照配置
- 手動save/bgsave命令
- 執行flushall/flushdb命令也會產生dump.rdb文件，但里面是空的，無意義
- 執行shutdown且沒有設置開啟AOF持久化
- 主從復制時，主節點自動觸發
3.16 如何禁用快照
- 命令方式:
redis-cli config set save ""
- 修改配置文件：
3.17 RDB優化配置項詳解
- stop-writes-on-bgsave-error
默認yes
如果配置成no，表示你不在乎數據不一致或者有其他的手段發現和控制這種不一致，那么在快照寫入失敗時，
也能確保redis繼續接受新的寫請求
- rdbcompression
默認yes
對于存儲到磁盤中的快照，可以設置是否進行壓縮存儲。如果是的話，redis會采用LZF算法進行壓縮。
如果你不想消耗CPU來進行壓縮的話，可以設置為關閉此功能
- rdbchecksum
默認yes
在存儲快照后，還可以讓redis使用CRC64算法來進行數據校驗，但是這樣做會增加大約10%的性能消耗，如果希望獲取到最大的性能提升，可以關閉此功能
- rdb-del-sync-files
rdb-del-sync-files：在沒有持久性的情況下刪除復制中使用的RDB文件啟用。默認情況下no，此選項是禁用的。
3.2 持久化方式2：AOF
AOF（Append Only File）模式是另一種常用的持久化模式。它會將每個寫操作都追加到一個日志文件中，從而記錄了Redis的所有操作命令。在恢復數據時，Redis會重新執行這些操作命令以還原數據。AOF模式的優點在于數據的持久化更加可靠，不會丟失任何寫操作。然而，由于需要記錄每一條寫命令，相對于RDB模式，AOF模式的寫入性能較差。
適用場景： 對數據的可靠性要求較高，需要最大程度地避免數據丟失的場景
3.2.1 AOF持久化工作流程
| 序號 | 描述 |
|---|---|
| 1 | Client作為命令的來源，會有多個源頭以及源源不斷的請求命令。 |
| 2 | 在這些命令到達Redis Server以后并不是直接寫入AOF文件，會將其這些命令先放入AOF緩存中進行保存。這里的AOF緩沖區實際上是內存中的一片區域，存在的目的是當這些命令達到一定量以后再寫入磁盤，避免頻繁的磁盤IO操作。 |
| 3 | AOF緩沖會根據AOF緩沖區同步文件的三種寫回策略將命令寫入磁盤上的AOF文件。 |
| 4 | 隨著寫入AOF內容的增加為避免文件膨脹，會根據規則進行命令的合并(又稱AOF重寫)，從而起到AOF文件壓縮的目的。 |
| 5 | 當Redis Server服務器重啟的時候會從AOF文件載入數據。 |
3.2.2 三種寫回策略
| 配置項 | 寫回時機 | 優點 | 缺點 |
|---|---|---|---|
| Always | 同步寫回 | 可靠性高，數據基本不丟失 | 每個寫命令都要落盤，性能影響較大 |
| Everysec(默認) | 每秒寫回 | 性能適中 | 宕機時丟失1秒內的數據 |
| No | 操作系統控制 | 性能好 | 宕機時丟失數據較多 |
3.2.3 AOF配置說明
| 配置指令 | 描述 | 配置示例 |
|---|---|---|
| appendonly | 是否開啟AOF | appendonly yes |
| appendfilename | AOF文件名稱 | appendfilename “appendonly.aof” |
| dir+appenddirname | AOF文件路徑 | dir /myredis+“appendonlydir” |
| appendfsync | AOF同步寫回方式 | everysec/always/no |
| no-appendfsync-on-rewrite | AOF重寫期間是否同步寫回 | no-appendfsync-on-rewrite no |
| auto-aof-rewrite-percentage auto-aof-rewrite-min-size | AOF重寫觸發配置，觸發重寫的比例閾值和最小文件大小閾值； 滿足配置文件中的選項后，Redis會記錄上次重寫時的AOF大小 默認配置是當AOF文件大小是上次rewrite后大小的一倍目文件大于64M時 | auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb |
3.2.4 AOF文件說明
Redis7.0 Multi Part AOF的設計
顧名思義，MP-AOF就是將原來的單個AOF文件拆分成多個AOF文件(redis6只有一個文件)。在MP-AOF中，我們將AOF分為三種類型分別為:
它一般由子進程通過重寫產生，該文件最多只有一個
- BASE: 表示基礎AOF
- INCR: 表示增量AOF，
它一般會在AOFRW開始執行時被創建，該文件可能存在多個。 - HISTORY: 表示歷史AOF，它由BASE和INCR AOF變化而來，每次AOFRW成功完成時本次AOFRW之前對應的BASE和INCR AOF都將變為HISTORY，HISTORY類型的AOF會被Redis自動刪除為了管理這些AOF文件我們引入了一個manifest (清單) 文件來跟蹤、管理這些AOF。同時，為了便于AOF備份和拷貝，我們將所有的AOF文件和manifest文件放入一個單獨的文件目錄中，目錄名由appenddirname配置
(Redis 7.0新增配置項) 決定。
// 如有下的aof文件存在
1.基本文件
appendonly.aof.1base .rdb
2.增量文件
appendonly.aof.1.incr.aof
appendonly.aof.2.incr.aof
3.清單文件
apendonly.aof.manifest
AOF路徑說明
redis7.0 AOF文件路徑：dir + appenddirname 其中
- dir是RDB和AOF共用配置參數
- appenddirname 是redis7新增的aof獨特配置
// 幾種類型文件的前綴,后跟有關序列和類型的附加信息
appendfilename"appendonly.aof
//新版本增加的目錄配置項目
appenddirname "appendonlydir"
3.2.5 AOF恢復
采用 flushdb + shutdown模擬redis異常終止，需要注意的是：
flushdb也是寫操作，也會寫入aof文件，所以在執行flushdb之前備份aof文件，flushdb之后可以使用 備份的aof 覆蓋掉aof文件- 也可以不備份，在執行完
flushdb + shutdown操作之后，手動刪除增量文件中的最后flushdb命令 - 為了防止RDB文件的干涉，重啟之前刪除RDB文件，或者模擬整個過程中關閉RDB持久化
最后，重啟reids便可加載aof文件進行數據恢復
3.2.6 AOF文件修復
故意破環aof增量文件
[root@Docker110 appendonlydir]# vim appendonly.aof.1.incr.aof
*2
$6
......
$1
0
jasitfgjwaior943q294r534jiosa(*(u
重啟啟動之后查看
居然啟動失敗，趕緊查看一下日志，日志文件
日志文件路徑的配置
建議讓我們修復一下aof文件
再次啟動，成功恢復
3.2.7 AOF重寫機制
AOF 文件的不斷增長可能會導致性能問題。為了解決這個問題，Redis 實現了 AOF 重寫機制。AOF 重寫是一種優化技術，通過在后臺進程中重構 AOF 文件的數據，來減小 AOF 文件的大小。
啟動AOF文件的內容壓縮，只保留可以恢復數據的最小指令集
也就是說 AOF 文件重寫并不是對原文件進行重新整理，而是直接讀取服務器現有的鍵值對，
然后用一條命令去代替之前記錄這個鍵值對的多條命令，生成一個新的文件后去替換原來的 AOF 文件。
AOF 文件重寫觸發機制: 過 redis.conf 配置文件中的 auto-aofrewrite-percentage: 默認值為100，以及auto-aofrewritemin-size: 64mb 配置，
也就是說默認Redis會記錄上次重寫時的AOF大小，默認配置是當AOF文件大小是上次rewrite后大小的一倍目文件大于64M時觸發
- 重寫機制的配置
注意 ，同時滿足，且的關系才會觸發
1 根據上次重寫后的aof大小，判斷當前aof大小是不是增長了1倍
2 重寫時滿足的文件大小
- 觸發方式
1. 自動觸發：滿足重寫機制配置條件，就會自動后臺執行重寫，也就是壓縮aof
2. 手動觸發: 客戶端向服務器發送 bgrewriteaof 命令
- 重寫原理
1.AOF 重寫機制的原理是根據 Redis 進程內的數據生成一個新的 AOF 文件，只包含當前有效和存在的數據的寫入命令，而不是歷史上所有的寫入命令 。
2.AOF 重寫機制是通過 fork 出一個子進程來完成的，子進程會掃描 Redis 的數據庫，并將每個鍵值對轉換為相應的寫入命令，然后寫入到一個臨時文件中 。
3.在子進程進行 AOF 重寫的過程中，主進程還會繼續接收和處理客戶端的請求，如果有新的寫操作發生，主進程會將這些寫操作追加到一個緩沖區中，并通過管道通知子進程 。
4.子進程在完成 AOF 重寫后，會將緩沖區中的寫操作也追加到臨時文件中，然后向主進程發送信號，通知主進程可以切換到新的 AOF 文件了 。
5.主進程在收到子進程的信號后，會將緩沖區中的寫操作再次追加到臨時文件中（以防止在此期間有新的寫操作發生），然后用臨時文件替換舊的 AOF 文件，并關閉舊的 AOF 文件
- 驗證
文件大小調整為 1k 方便驗證
反復多次設置k1
查看增量aof內容的的變化、aof文件名稱以及大小的變化
可以清晰的看到重寫之后的變化：
- base基礎aof由0變成130、增量aof由384變成0、清單aof沒有變化，整體大小進行了壓縮
- 文件序號由1變成了
3.2.8 總結
更好的保護數據不丟失 、性能高、可做緊急恢復相同數據集的數據而言aof文件要遠大于rdb文件，恢復速度慢于rdbaof運行效率要慢于rdb,每秒同步策略效率較好，不同步效率和rdb相同
3.3 持久化方式3：混合模式RDB+AOF
3.3.1 混合模式介紹
我們首先看看官網對混合模式的介紹：
一般來說，如果你想要一個與PostgreSQL相媲美的數據安全程度，你應該使用這兩種持久化方法。RDB鏡像做全量持久化，AOF做增量持久化
結合了RDB和AOF的優點，既能快速加載又能避免丟失過多的數據
3.3.2 開啟混合方式設置
設置aof-use-rdb-preamble的值為 yes yes表示開啟，設置為no表示禁用
先使用RDB進行快照存儲，然后使用AOF持久化記錄所有的寫操作，當重寫策略滿足或手動觸發重寫的時候，將最新的數據存儲為新的RDB記錄。這樣的話，重啟服務的時候會從RDB和AOF兩部分恢復數據，既保證了數據完整性，又提高了恢復數據的性能。
簡單來說：混合持久化方式產生的文件一部分是RDB格式，一部分是AOF格式(AOF包括了RDB頭部+AOF混寫)
3.3.3 數據的加載流程
在同時開啟rdb 和aof 持久化時，重啟時只會加載 aof 文件，不會加載 rdb 文件，rdb做為一個萬一的策略
3.4 純緩存模式
同時關閉RDB+AOF
- 禁用RDB(
save "")
禁用RDB持久化模式下，我們仍然可以使用命令save、bgsave生成rdb文件 - 禁用AOF(
appendonly no)
禁用AOF持久化模式下，我們仍然可以使用命令bgrewriteaof生成aof文件
4. 參考和感謝
尚硅谷Redis零基礎到進階，最強redis7教程，陽哥親自帶練
more命令)
)
