AOF

保存寫操作命令到日志的持久化方式，就是Redis里的AOF持久化功能（先寫入到內存，再將記錄命令寫到日志同步到磁盤中）

三種寫回策略

Always，這個單詞的意思是「總是」，所以它的意思是每次寫操作命令執行完后，同步將 AOF 日志數據寫回硬盤；
Everysec，這個單詞的意思是「每秒」，所以它的意思是每次寫操作命令執行完后，先將命令寫入到 AOF 文件的內核緩沖區，然后每隔一秒將緩沖區里的內容寫回到硬盤；
No，意味著不由 Redis 控制寫回硬盤的時機，轉交給操作系統控制寫回的時機，也就是每次寫操作命令執行完后，先將命令寫入到 AOF 文件的內核緩沖區，再由操作系統決定何時將緩沖區內容寫回硬盤。

寫回策略的優缺點

Always：保證數據的持久性和一致性，但寫入性能較低。高可靠
Everysec：在性能和數據持久性之間做了一定的平衡，適用于大多數應用場景。折中
No：寫入性能最高，但在崩潰時可能會丟失數據，適用于對數據持久性要求不高或可以容忍少量數據丟失的場景。高性能

$[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-ZMzslZl4-1691542607867)(C:\Users\hp\AppData\Roaming\Typora\typora-user-images\image-20230809080739581.png)]$

深入底層三種寫回策略，其實調用fsync()函數的時機不同：

Always 策略就是每次寫入 AOF 文件數據后，就執行 fsync() 函數；
Everysec 策略就會創建一個異步任務來執行 fsync() 函數；
No 策略就是永不執行 fsync() 函數;

AOF 重寫機制

為了避免AOF文件越寫越大，提供了AOF重寫機制，當文件超過閥值就會啟動AOF重寫機制，來壓縮文件，重寫機制的妙處在于，盡管某個鍵值對被多條寫命令反復修改，最終也只需要根據這個「鍵值對」當前的最新狀態，然后用一條命令去記錄鍵值對，代替之前記錄這個鍵值對的多條命令，這樣就減少了 AOF 文件中的命令數量。最后在重寫工作完成后，將新的 AOF 文件覆蓋現有的 AOF 文件。

AOF后臺重寫

AOF重寫很耗時，所以，Redis 的重寫 AOF 過程是由后臺子進程 *bgrewriteaof* 來完成的，這么做可以達到兩個好處：

子進程進行 AOF 重寫期間，主進程可以繼續處理命令請求，從而避免阻塞主進程；
子進程帶有主進程的數據副本（數據副本怎么產生的后面會說），這里使用子進程而不是線程，因為如果是使用線程，多線程之間會共享內存，那么在修改共享內存數據的時候，需要通過加鎖來保證數據的安全，而這樣就會降低性能。而使用子進程，創建子進程時，父子進程是共享內存數據的，不過這個共享的內存只能以只讀的方式，而當父子進程任意一方修改了該共享內存，就會發生「寫時復制」，于是父子進程就有了獨立的數據副本，就不用加鎖來保證數據安全。

AOF優缺點

AOF（Append-Only File）持久化是 Redis 的一種持久化機制，它將所有的寫操作追加到一個文件中，通過重新執行這些寫操作來恢復數據。

AOF 持久化的優點包括：

數據完整性：AOF 持久化可以保證數據的完整性和持久性，每個寫操作都會被追加到文件中，從而避免了數據丟失的風險。
靈活性：AOF 持久化采用追加寫入的方式，因此可以在不中斷服務的情況下進行持久化操作，提供了更好的靈活性。
可讀性：AOF 文件是一個追加寫入的日志文件，可以通過文本編輯器查看其中的寫操作，方便進行故障排查和數據恢復。
高性能：AOF 持久化的寫入性能通常比 RDB（Redis 數據庫快照持久化）更高，尤其在寫入頻率較高的場景下。

AOF 持久化的缺點包括：

文件體積較大：AOF 文件相對于 RDB 文件通常會更大，因為它包含了所有的寫操作。這可能會占用更多的磁盤空間。
恢復速度較慢：由于 AOF 持久化是通過重新執行寫操作來恢復數據的，當 AOF 文件較大時，恢復過程可能比 RDB 持久化更慢。
可能存在數據冗余：由于 AOF 文件記錄了所有的寫操作，可能會導致一些數據操作的冗余，尤其是在寫入頻率較高的情況下。

需要根據具體的業務需求、數據安全性和性能要求來選擇合適的持久化方式。可以采用 AOF 持久化來提供更好的數據完整性和靈活性，但也要注意管理 AOF 文件的大小和恢復速度。

使用命令

需要使用CONFIG命令來修改appendonly參數的值（Yes/No）

RDB

AOF文件的內容是操作命令
RDB文件的內容是二進制數據

Redis 提供了兩個命令來生成 RDB 文件，分別是 save 和 bgsave，他們的區別就在于是否在「主線程」里執行：

執行了 save 命令，就會在主線程生成 RDB 文件，由于和執行操作命令在同一個線程，所以如果寫入 RDB 文件的時間太長，會阻塞主線程；
執行了 bgsave 命令，會創建一個子進程來生成 RDB 文件，這樣可以避免主線程的阻塞；

Redis 的快照是全量快照，也就是說每次執行快照，都是把內存中的「所有數據」都記錄到磁盤中。

Redis RDB（Redis Database）是一種快照持久化機制，用于將 Redis 的內存數據保存到磁盤上的二進制文件中。

RDB 持久化的工作原理

Redis 通過fork一個子進程來執行持久化操作，父進程繼續處理客戶端請求。
子進程將當前的內存數據快照寫入到臨時文件中。
寫入完成后，子進程將臨時文件重命名為持久化文件（默認名為dump.rdb）。
Redis 將舊的持久化文件（如果存在）替換為新的持久化文件。

執行快照時，數據能被修改嗎

執行 bgsave 過程中，Redis 依然可以繼續處理操作命令的，也就是數據是能被修改的，關鍵的技術就在于寫時復制技術（Copy-On-Write, COW）。

RDB 持久化是通過將 Redis 的內存數據快照寫入磁盤的方式來實現的。為了保證數據的一致性，Redis 在執行 RDB 快照時會使用子進程來處理持久化操作，而父進程繼續處理客戶端請求。在子進程執行 RDB 快照期間，父進程仍然可以處理客戶端的寫操作。這意味著，在執行 RDB 持久化期間，Redis 可能會接收到新的寫操作，并且這些寫操作會修改內存中的數據。然而，這些被修改的數據不會被立即寫入到 RDB 文件中。子進程在完成 RDB 持久化后，會將當前內存中的數據快照寫入到臨時文件中，并將臨時文件重命名為持久化文件。因此，在 RDB 快照執行期間，寫操作對于持久化操作來說是不可見的。

RDB 持久化的優點

性能較高：RDB 持久化是通過將內存數據快照寫入磁盤的方式來實現持久化，速度較快，適合大規模數據的備份和恢復。
文件體積較小：RDB 文件是二進制格式，相對于 AOF（Append-Only File）持久化產生的日志文件，文件體積較小，節省磁盤空間。
恢復速度較快：由于 RDB 文件是 Redis 數據的快照，恢復數據時只需加載 RDB 文件即可，速度較快。

RDB 持久化的缺點

可能會丟失數據：RDB 持久化是通過周期性地將內存數據快照寫入磁盤來實現的，如果 Redis 在持久化之間發生崩潰，可能會丟失最后一次持久化后的數據。
不適合實時備份：RDB 持久化是通過在后臺進行快照操作來實現的，不適合實時備份，因此在數據恢復時可能會丟失最新的數據。

需要根據具體的業務需求、數據安全性和性能要求來選擇合適的持久化方式。可以使用 RDB 持久化來提供較高的性能和較小的文件體積，但需要注意定期執行持久化操作以避免數據丟失。

混合持久化

aof-use-rdb-preamble yes

混合持久化工作在AOF日志重寫過程

當開啟了混合持久化時，在 AOF 重寫日志時，fork 出來的重寫子進程會先將與主線程共享的內存數據以 RDB 方式寫入到 AOF 文件，然后主線程處理的操作命令會被記錄在重寫緩沖區里，重寫緩沖區里的增量命令會以 AOF 方式寫入到 AOF 文件，寫入完成后通知主進程將新的含有 RDB 格式和 AOF 格式的 AOF 文件替換舊的的 AOF 文件。

也就是說，使用了混合持久化，AOF 文件的前半部分是 RDB 格式的全量數據，后半部分是 AOF 格式的增量數據。這樣的好處在于，重啟 Redis 加載數據的時候，由于前半部分是 RDB 內容，這樣加載的時候速度會很快。加載完 RDB 的內容后，才會加載后半部分的 AOF 內容，這里的內容是 Redis 后臺子進程重寫 AOF 期間，主線程處理的操作命令，可以使得數據更少的丟失。

大key對持久化的影響

Redis 中的大 key 指的是占用比較大的鍵值對，通常是字符串類型的值，其大小超過了 Redis 的配置參數 hash-max-ziplist-value（默認為 64 字節）或 list-max-ziplist-value（默認為 8KB）。

大 key 對持久化的影響如下：

RDB 持久化：在執行 RDB 持久化時，Redis 會將內存中的數據快照寫入到磁盤的 RDB 文件中。如果存在大 key，特別是大字符串類型值，會導致 RDB 文件的大小增加，從而增加持久化操作的耗時和占用的磁盤空間。
AOF 持久化：在執行 AOF 持久化時，Redis 會將寫操作追加到 AOF 文件中。如果存在大 key，每次對該鍵進行修改操作時，都會導致 AOF 文件的增長，從而增加持久化操作的耗時和占用的磁盤空間。

大 key 對持久化的影響主要體現在持久化文件的大小和持久化操作的性能上。較大的持久化文件可能會增加恢復數據的時間，而頻繁的持久化操作可能會降低 Redis 的寫入性能。

為了減少大 key 對持久化的影響，可以考慮以下措施：

將大 key 拆分為多個較小的鍵值對，以減少單個鍵值對的大小。
對于大字符串類型值，可以考慮是否需要拆分為多個較小的字符串進行存儲。
根據業務需求和數據訪問模式，合理設置 Redis 的配置參數，如 hash-max-ziplist-value 和 list-max-ziplist-value，以控制大 key 的大小。