什么是Redis持久化：

Redis 持久化是指將 Redis 內存中的數據保存到硬盤等持久化存儲介質中，以便在 Redis 服務器重啟或出現故障時能夠恢復數據，保證數據的可靠性和持續性。Redis 提供了兩種主要的持久化方式：RDB（Redis Database）持久化和 AOF（Append Only File）持久化。

我們可以采取的方案有四個：

1. RDB持久化
2. AOF持久化
3. RDB+AOF
4. 不做任何持久化的操作

RDB持久化概念：

RDB 持久化是將 Redis 在某一時刻的內存數據快照保存到磁盤上的一種持久化方式，它生成的文件是一個緊湊的二進制文件，也被稱為 RDB 文件。

?RDB基礎配置：

?

redis可以通過命令：config get <String 字段名> 獲取配置文件中的值。

小編當前的Redis版本是：redis-6.2.7 版本

觸發機制：

自動觸發

RDB 持久化可以根據配置文件中設置的自動保存條件觸發。自動保存條件通常是基于時間和數據變化量來設置的，例如 “save 900 1” 表示在 900 秒內如果至少有 1 個鍵發生了變化，就會觸發 RDB 快照。

版本區別：

在redis的6.2~7的版本我們的觸發機制出現了變化，在之前的版本中，我們的自動觸發時間有了變化。

在6.0.16及之前的版本中，默認時間是：

如果沒有手動配置 RDB 持久化的觸發時間，Redis 默認的觸發條件：

• save 900 1：表示 900 秒（15 分鐘）內至少有 1 個鍵被更改時，觸發 RDB 快照。
• save 300 10：即 300 秒（5 分鐘）內至少有 10 個鍵被更改時，執行 RDB 持久化操作。
• save 60 10000：意味著 60 秒內至少有 10000 個鍵被更改，會觸發 RDB 快照。

在新版中，他的時間變為了

數據的恢復：

FLUSHALL?和?FLUSHDB?是 Redis 中用于清空數據的命令，如果我們執行這兩個數據時，也會產生dump.rdb文件，這個rdb文件就是空的了。是沒有意義的

我們使用shutdown命令關閉redis時，也會產生rdb文件，將當前快照保存。

SHUTDOWN?命令的主要作用是關閉 Redis 服務器。在關閉之前，它會先執行持久化操作，確保內存中的數據按照配置的持久化策略保存到磁盤，之后再正常關閉服務。

假設我們將一個時間的快照保存下來，將這個文件復制一份放置到別的文件夾下，之后用的時候按著這個文件回復當前快照的數據。

redis在啟動時，按著我們這個文件進行恢復。

在物理恢復時，我們要將redis服務器和備份文件分開各自存儲，放置生產機物理損壞之后備份文件掛到。（備份隔離）

?手動觸發：

RDB 持久化可以通過手動執行命令（如 SAVE 或 BGSAVE）來觸發。

SAVE：這是一個同步命令。當你在 Redis 客戶端輸入?SAVE?命令后，Redis 服務器會立即停止處理客戶端的其他請求，全身心投入到將內存中的數據寫入 RDB 文件的工作中。只有當數據全部寫入完成，生成 RDB 文件后，服務器才會繼續響應其他客戶端的請求。

BGSAVE（默認）：這是一個異步命令。當執行?BGSAVE?命令時，Redis 服務器會 fork 出一個子進程。這個子進程負責將內存中的數據寫入 RDB 文件，而父進程（也就是主 Redis 進程）會繼續處理客戶端的請求，不會被阻塞。

生產上是bgsave,不能是save

通過lastsave 獲取最后一次成功執行的快照時間

Linux上轉化時間戳的命令：

[root@localhost bin]# date -d @15454545
1970年 06月 29日 星期一 04:55:45 CST

優缺點

• 優點：
  • 數據恢復快：RDB 文件是一個緊湊的二進制文件，在恢復數據時，Redis 可以快速地將 RDB 文件中的數據加載到內存中，相比其他一些持久化方式，恢復速度通常較快。
  • 適合大規模數據備份：RDB 文件可以方便地進行備份和傳輸，適合用于數據的遠程備份和歸檔，例如可以定期將 RDB 文件復制到其他存儲設備或遠程服務器上。
  • 對性能影響小：在生成 RDB 文件時，使用子進程進行數據寫入，對 Redis 主進程的性能影響相對較小，特別是在數據量較大時，這種方式的性能優勢更為明顯。
• 缺點：
  • 數據一致性問題：RDB 持久化是基于一定的時間間隔進行數據快照的，所以在兩次快照之間如果發生服務器故障，可能會丟失一部分數據。例如，如果設置了每 5 分鐘進行一次 RDB 快照，那么在這 5 分鐘內的數據變化在服務器故障時就可能會丟失。
  • 內存占用問題：在生成 RDB 文件時，需要 fork 子進程，而子進程會復制父進程的內存空間，這在內存占用上會有一定的開銷，特別是在內存數據量較大的情況下，可能會導致短暫的內存壓力。

RDB文件的修復

假設我們的rdb文件再寫入時出現了破損。該如何修復呢：

命令行：./redis-check-rdb dump.rdb

?那些情況會出現dump.rdb文件：

1. 符合save后的觸發情況
2. 手動的save,bgsave命令
3. 執行flushadd,flushdb命令，但是文件是空的
4. 執行shutdown，并且沒有開啟AOF持久化
5. 主從復制時，主節點自動觸發

如何禁用快照：

執行命令，動態禁用：config set save ""

修改配置文件，添加??save ""? 就會禁用

優化配置項：

默認yes 如果配置成no，表示你不在乎數據不一致或者有其他的手段發現和控制這種不一致，那么在快照寫入失敗時， 也能確保redis繼續接受新的寫請求

默認yes

對于存儲到磁盤中的快照，可以設置是否進行壓縮存儲。如果是的話，redis會采用LZF算法進行壓縮。 如果你不想消耗CPU來進行壓縮的話，可以設置為關閉此功能

默認yes

在存儲快照后，還可以讓redis使用CRC64算法來進行數據校驗，但是這樣做會增加大約10%的性能消耗，如果希望獲取到最大的性能提升，可以關閉此功能

rdb-del-sync-files：在沒有持久性的情況下刪除復制中使用的RDB文件啟用。默認情況下no，此選項是禁用的。?

AOF持久化：

AOF 持久化是通過將 Redis 服務器接收到的每一條寫命令追加到一個以追加模式打開的文件中，來記錄數據庫的變化。當 Redis 服務器重啟時，它會重新執行 AOF 文件中的命令，以重建數據庫狀態，從而實現數據的恢復。

默認是不開啟的，需要配置我們的配置文件。講appendonly 設置為yes

aop寫入流程：

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

三種寫回策略：

Always:同步回寫，每個寫命令執行之后立刻同步將日志寫回到磁盤（IO頻繁）

everysec:(默認)：每秒寫回，每個寫命令執行完，只是先把日志寫道AOF文件的內存緩沖區中，每秒寫入到磁盤中，每秒寫一次

no:操作系統控制的寫回，每個寫命令執行完，只是先把日志寫道AOF文件的內存緩沖區中，有操作系統決定何時將數據寫入到磁盤。

AOF配置的設置：

?在redis配置文件中redis7中對于AOF上有很大的優化。下文中介紹6和7的配置文件講解。

打開AOF持久化機制：

設置寫回策略：

?在打開之后，我們只要就會發現在我們的路徑之下出現了一個文件appendonly.aof

設置AOF文件保存路徑：

在這里我們的redis有了變化：

在我們的redis6中，他的文件的位置和我們的的dump.rdb文件位置是一致的，都是通過config中的dir設置。

在redis7中，我們dir下，RDB文件的位置不變，但是在這個位置會出現一個子文件夾，子文件夾的名字就是我們appenddirname鍵值對的值

設置AOF文件保存名稱：

redis6中，名字就是

在redis7中，不再是一個aof文件，變成了三個文件

官網的信息是：

aof文件的修復：

假設我們的aof文件出現問題時：例如我們當前的寫入數據大，一秒寫入時沒有寫完，但是在下一秒redis直接宕機，這是我們的redis在aof文件出現問題時，沒有辦法運行redis.需要進行文件修復。

檢查環境變量的命令是：echo $PATH

修復的命令是：redis-check-aof --fix? <String fileName>

AOF的優缺點：

優點

1. 數據安全性高

• AOF 持久化以日志形式記錄寫操作，默認配置下，即使服務器發生故障，最多只會丟失 1 秒鐘內執行的寫命令。這是因為 Redis 可以配置為每秒將 AOF 緩沖區中的內容同步到磁盤，若使用always同步策略，每個寫命令都會立即同步到磁盤，最大程度減少數據丟失風險。
• 相比 RDB（Redis Database）持久化在特定時間點生成快照，AOF 能更及時地記錄數據變更，在遇到服務器崩潰等異常情況時，能更好地保證數據完整性。

2. 日志文件可讀性強

• AOF 文件是一個純文本文件，記錄的是 Redis 執行的寫命令，例如SET key value、INCR counter等。這使得管理員可以方便地查看和分析文件內容，排查問題。
• 當需要恢復數據時，可以直接查看 AOF 文件，了解數據的變更歷史，必要時還能手動修改文件內容。

3. 易于實現數據恢復

• 在 Redis 重啟時，會按照 AOF 文件中記錄的命令順序依次執行，將數據恢復到故障前的狀態。
• 與 RDB 相比，AOF 在數據恢復過程中不需要像 RDB 那樣等待生成快照文件，恢復速度通常更快，尤其對于數據量較大的場景，優勢更明顯。

4. 支持追加式寫入

• AOF 文件采用追加方式寫入，寫操作是順序的，避免了隨機磁盤 I/O，提高了寫入性能。
• 隨著 Redis 服務器的運行，新的寫命令會不斷追加到 AOF 文件末尾，不會影響之前已記錄的內容。

缺點

1. AOF 文件體積較大

• 由于 AOF 文件記錄了所有寫命令，隨著時間推移和服務器的持續運行，文件會不斷增大。
• 對于頻繁執行寫操作的 Redis 實例，AOF 文件可能會變得非常龐大，占用大量磁盤空間，同時也會增加文件管理和傳輸的難度。

2. 恢復速度可能較慢

• 雖然一般情況下 AOF 恢復速度比 RDB 快，但在 AOF 文件非常大時，Redis 在重啟時需要執行大量的命令來恢復數據，這會導致恢復時間變長。
• 特別是在使用always同步策略時，由于每次寫命令都要同步到磁盤，會產生更多的 I/O 操作，進一步影響恢復速度。

3. 性能開銷較大

• 與 RDB 持久化相比，AOF 持久化需要更多的磁盤 I/O 操作。尤其是在使用always同步策略時，每個寫命令都會立即同步到磁盤，會顯著降低 Redis 的寫性能。
• 即使使用everysec（每秒同步一次）策略，在高并發寫操作場景下，頻繁的磁盤 I/O 也會成為性能瓶頸。

4. AOF 重寫帶來額外開銷

• 為了解決 AOF 文件體積過大的問題，Redis 會定期或手動執行 AOF 重寫操作，將 AOF 文件中的冗余命令合并。
• AOF 重寫過程需要消耗額外的 CPU 和內存資源，可能會對 Redis 服務器的性能產生一定影響。

AOF重寫機制：

自動觸發:

在我們的aof文件較大時(達到閾值時),就會觸發aof文件的重寫,重寫的文件會對指令進行壓縮,新的文件中只是保留可以恢復數據的最小指令集.

閾值大小是:

redis7配置文件:

redis6配置文件:

配置文件沒有變化,他的意思是文件大小變為以前的2倍,并且大于64mb機會觸發重寫.?

但是對于7和6的文件的寫的格式是不一樣的.

redis7:

在我們的incr文件達到閾值時,開始進行?重寫,這時我們的重寫結束后我們的文件名也會發生變化

手動觸發:

執行客戶端命令:

BGREWRITEAOF

整體上重寫的過程

這里需要考率的是如果在重寫時我們的數據還在繼續的寫入,這是整體的流程是什么:

1：在重寫開始前，redis會創建一個“重寫子進程”，這個子進程會讀取現有的AOF文件，并將其包含的指令進行分析壓縮并寫入到一個臨時文件中。(其實這里也是他的缺點,子進程加大內存開銷)

2：與此同時，主進程會將新接收到的寫指令一邊累積到內存緩沖區中，一邊繼續寫入到原有的AOF文件中，這樣做是保證原有的AOF文件的可用性，避免在重寫過程中出現意外。

3：當“重寫子進程”完成重寫工作后，它會給父進程發一個信號，父進程收到信號后就會將內存中緩存的寫指令追加到新AOF文件中

4：當追加結束后，redis就會用新AOF文件來代替舊AOF文件，之后再有新的寫指令，就都會追加到新的AOF文件中

5：重寫aof文件的操作，并沒有讀取舊的aof文件，而是將整個內存中的數據庫內容用命令的方式重寫了一個新的aof文件，這點和快照有點類似

RDB+AOF混合持久化:

如果使用這種方式持久化時,他們的優先級是:

在同時開啟時,優先加載的時aof文件.?

官網推薦使用兩種方式共存的形式進行數據持久化操作.

如何開啟混合模式:

開啟的配置:

這個配置的前置條件是必須開啟aof.

注意點:

在 Redis 中，aof-use-rdb-preamble?和?appendonly?是兩個不同的配置項，它們分別控制著 AOF（Append Only File）持久化相關的不同特性。下面來分析設置?aof-use-rdb-preamble?為?yes?時，若?appendonly?設置為?no?是否能達成預期目的。

配置項含義

• aof-use-rdb-preamble：這個配置項用于控制 AOF 重寫時的文件格式。當設置為?yes?時，AOF 重寫后的文件開頭會包含一個 RDB 格式的快照，之后才是 AOF 格式的增量命令。這種方式能讓 AOF 文件在恢復數據時，先利用 RDB 快照快速加載大部分數據，再通過執行 AOF 中的增量命令來恢復最新的數據，提升恢復速度。
• appendonly：此配置項用于開啟或關閉 AOF 持久化功能。當設置為?yes?時，Redis 會開啟 AOF 持久化，將寫命令追加到 AOF 文件中；當設置為?no?時，Redis 會關閉 AOF 持久化，僅使用 RDB 持久化（如果開啟了 RDB 持久化的話）。

分析設置結果

當?aof-use-rdb-preamble?設置為?yes，而?appendonly?設置為?no?時，無法達成使用?aof-use-rdb-preamble?特性的目的。原因如下：

?

• aof-use-rdb-preamble?特性是基于 AOF 持久化的，它主要影響 AOF 重寫后的文件格式。若?appendonly?設置為?no，AOF 持久化功能被關閉，Redis 不會生成 AOF 文件，也就不存在 AOF 重寫操作，那么?aof-use-rdb-preamble?的配置就沒有實際意義。

示例配置說明

假設你有如下配置需求：

?

plaintext

aof-use-rdb-preamble yes
appendonly no

?

在這種配置下，由于?appendonly?為?no，Redis 不會開啟 AOF 持久化，即使?aof-use-rdb-preamble?設置為?yes，也不會有包含 RDB 預 amble 的 AOF 文件生成。

?

若你想使用?aof-use-rdb-preamble?特性來優化 AOF 文件恢復速度，需要將?appendonly?設置為?yes，示例配置如下：

?

plaintext

aof-use-rdb-preamble yes
appendonly yes

?

這樣配置后，Redis 會開啟 AOF 持久化，并且在 AOF 重寫時會采用包含 RDB 預 amble 的文件格式。

?

綜上所述，設置?aof-use-rdb-preamble?為?yes?時，若?appendonly?設置為?no，無法達成使用該特性的目的，需要將?appendonly?設置為?yes?才能生效。

純緩存模式:

同時關閉RDB和AOF

關閉RDB:save ""? 關閉AOF:appendonly no? ?

即使是關閉之后依舊可以使用save,bgsave生成RDB文件,使用bgrewriteaof生成aof文件。

這是redis就只是一個緩存的作用。