Redis 支持多種持久化方式來保證數(shù)據(jù)的可靠性和持久性。前面我們介紹了RDB方式。我們我們介紹第二種方式——AOF（Append Only File）機(jī)制是一種常用的持久化方式，它記錄了所有對 Redis 數(shù)據(jù)庫進(jìn)行修改的命令，在 Redis 重啟時可以使用這些命令來重構(gòu)數(shù)據(jù)庫狀態(tài)。?
目錄
1.AOF的基本原理
1.1 如何啟動AOF
1.2?AOF 文件的創(chuàng)建
1.3. AOF 文件的寫入
1.4. AOF 文件的重寫
1.5. AOF 文件的恢復(fù)
1.6. 小結(jié)
2. RDB和AOF混合方式
3 .AOF 持久化實(shí)踐
1.AOF的基本原理
1.1 如何啟動AOF
在 Redis 的配置文件中，可以通過以下配置項(xiàng)來設(shè)置?AOF?持久化相關(guān)的參數(shù)：
1. appendonly：設(shè)置是否開啟 AOF 持久化，默認(rèn)為 no（關(guān)閉狀態(tài)）。
2. appendfilename：設(shè)置 AOF 文件名，默認(rèn)為 appendonly.aof。
3. appendfsync：設(shè)置 AOF 文件同步策略，有以下三種可選值：
- always：每次寫入都會同步到磁盤，最安全但性能最差；
- everysec：每秒同步一次到磁盤，安全性和性能的折中方案；
- no：由操作系統(tǒng)決定何時同步，最不安全但性能最好。4. auto-aof-rewrite-percentage：設(shè)置 AOF 重寫觸發(fā)的條件之一，即 AOF 文件大小增長率達(dá)到該值時觸發(fā) AOF 重寫，默認(rèn)為 100。
5. auto-aof-rewrite-min-size：設(shè)置 AOF 重寫觸發(fā)的條件之一，即 AOF 文件大小達(dá)到該值時觸發(fā) AOF 重寫，默認(rèn)為 64MB。
6. aof-load-truncated：設(shè)置當(dāng) Redis 以 AOF 模式啟動時，是否自動修復(fù)截?cái)嗟?AOF 文件，默認(rèn)為 yes。
7. aof-use-rdb-preamble：設(shè)置是否在 AOF 文件中使用 RDB 文件的前綴，默認(rèn)為 yes。
修改 Redis 配置文件后，需要重啟 Redis 才能使配置生效。同時，對于 AOF文件同步策略的選擇，需要根據(jù)實(shí)際情況進(jìn)行權(quán)衡和選擇。如果對數(shù)據(jù)的安全性要求非常高，可以選擇 always
策略；如果對性能的要求比較高，可以選擇 everysec 策略。
1.2?AOF 文件的創(chuàng)建
當(dāng)啟用 AOF 持久化機(jī)制時，Redis 會在啟動時創(chuàng)建一個 AOF 文件，用于記錄所有寫命令。AOF 文件的默認(rèn)文件名為 appendonly.aof，可以通過配置文件中的 appendfilename 參數(shù)進(jìn)行修改。如果 AOF 文件已經(jīng)存在，則 Redis 會在啟動時讀取文件中的內(nèi)容，并將其加載到內(nèi)存中。
1.3. AOF 文件的寫入
當(dāng) Redis 執(zhí)行寫命令時，會將命令追加到 AOF 文件的末尾。如果 AOF 文件不存在，則 Redis 會自動創(chuàng)建一個新的 AOF 文件。如果 AOF 文件已經(jīng)存在，則 Redis 會將命令追加到文件的末尾。
Redis 為了提高寫入性能，通常會將多個命令緩存到內(nèi)存中，然后在滿足一定條件時批量寫入到 AOF 文件中。具體來說，Redis 會維護(hù)一個 AOF 緩沖區(qū)，將每個寫命令追加到緩沖區(qū)的末尾。當(dāng)緩沖區(qū)的大小超過一定閾值時，或者緩沖區(qū)中的命令已經(jīng)等待了一定時間后，Redis 會將緩沖區(qū)中的命令批量寫入到 AOF 文件中。
?
1.3. AOF 文件的同步
為了保證寫命令的可靠性和持久性，Redis 會在寫入 AOF 文件后進(jìn)行同步操作，將數(shù)據(jù)從內(nèi)存中刷到磁盤中。這就是我通常所說的刷盤操作。刷盤操作可以分為兩種方式：
- 同步磁盤上的所有數(shù)據(jù)，每次寫入 AOF 文件時，Redis 會調(diào)用 fsync 系統(tǒng)調(diào)用將數(shù)據(jù)從內(nèi)存刷到磁盤中。這種方式可以保證數(shù)據(jù)的可靠性，但是會帶來較大的性能損耗。
- 定期同步磁盤上的數(shù)據(jù)，Redis 也可以通過配置文件中的 appendfsync 參數(shù)來控制 AOF 文件的同步方式。其中，有三種常用的方式：
- always：每次寫入 AOF 文件時都進(jìn)行同步操作，可以保證數(shù)據(jù)的可靠性，但是會帶來較大的性能損耗。
- everysec：每秒鐘對 AOF 文件進(jìn)行一次同步操作，可以在一定程度上平衡數(shù)據(jù)安全和性能需求。
- no：不進(jìn)行同步操作，只在 Redis 進(jìn)程退出時進(jìn)行一次同步操作，可以提高性能，但是會帶來一定的數(shù)據(jù)風(fēng)險(xiǎn)。
這三種方式的對比，我們可以通過下面的表來判斷：
總結(jié)來說，就是：
- 如果要高性能，就選擇 No 策略；
- 如果要高可靠，就選擇 Always 策略；
- 如果允許數(shù)據(jù)丟失一點(diǎn)，但又想性能高，就選擇 Everysec策略。
1.4. AOF 文件的重寫
Redis AOF 文件在長時間運(yùn)行后可能會變得非常大，不僅占用磁盤空間，還會影響 Redis 的性能。為了解決這個問題，Redis 提供了 AOF 文件重寫機(jī)制，可以將 AOF 文件中的寫命令進(jìn)行壓縮，生成一條等效的命令序列，從而減少 AOF 文件的大小。
AOF 文件重寫機(jī)制的實(shí)現(xiàn)原理如下：
（1）Redis 會啟動一個新的子進(jìn)程，用于執(zhí)行 AOF 文件重寫操作。
（2）Redis 主進(jìn)程會將所有寫命令發(fā)送到子進(jìn)程中，子進(jìn)程會執(zhí)行這些命令，并生成一條等效的命令序列。
（3）子進(jìn)程會將等效命令序列寫入到一個新的 AOF 文件中，同時在寫入過程中進(jìn)行同步操作，保證數(shù)據(jù)的可靠性。
（4）當(dāng)子進(jìn)程完成 AOF 文件的重寫操作后，Redis 主進(jìn)程會將新的 AOF 文件重命名為原來的 AOF 文件，并刪除舊的 AOF 文件。
需要注意的是，AOF 文件重寫操作只會對已經(jīng)執(zhí)行過的寫命令進(jìn)行壓縮，新的寫命令仍然會被追加到 AOF 文件的末尾。Redis 會周期性地檢查 AOF 文件的大小，并在滿足一定條件時觸發(fā) AOF 文件重寫操作。
1.5. AOF 文件的恢復(fù)
AOF 的數(shù)據(jù)恢復(fù)過程設(shè)計(jì)很巧妙，它模擬一個 Redis 的服務(wù)過程。Redis 首先虛擬一個客戶端，讀取 AOF 文件恢復(fù) Redis 命令和參數(shù)；接著過程就和服務(wù)客戶端一樣執(zhí)行命令相應(yīng)的函數(shù)，從而恢復(fù)數(shù)據(jù)，這樣做的目的無非是提高代碼的復(fù)用率。這些過程主要在 loadAppendOnlyFile() 中實(shí)現(xiàn)。我們可以理解為假的重放。
真實(shí)的過程當(dāng) Redis 重啟時，會根據(jù) AOF 文件中記錄的命令重構(gòu)數(shù)據(jù)庫狀態(tài)。具體來說，Redis 會按照 AOF 文件中記錄的命令順序，逐個執(zhí)行命令，并在執(zhí)行過程中重建數(shù)據(jù)庫狀態(tài)。需要注意的是，AOF 文件的恢復(fù)過程可能會比較耗時，因此需要在 Redis 配置文件中設(shè)置 AOF 文件的恢復(fù)方式，可以選擇同步方式（always、everysec）或異步方式（no）。
所以，Redis AOF 持久化機(jī)制，其實(shí)說白了就是redis啟動的時候創(chuàng)建一個server.aof_buf的文件，通過一個文件，實(shí)現(xiàn)了將寫命令追加到 AOF 文件中，并在需要時同步到磁盤中，從而保證了數(shù)據(jù)的可靠性和持久性。 當(dāng)異常宕機(jī)需要恢復(fù)數(shù)據(jù)的時候又通過讀取文件，回放之前的命令，進(jìn)行數(shù)據(jù)還原。
由此大家也可以推斷出它存在的弊端。
1.6. 小結(jié)
對于相同的數(shù)據(jù)集來說，AOF 文件的體積通常要大于 RDB 文件的體積。
根據(jù)所使用的 fsync 策略，AOF 的速度可能會慢于 RDB 。
在一般情況下， 每秒 fsync 的性能依然非常高， 而關(guān)閉 fsync 可以讓 AOF 的速度和 RDB 一樣快， 即使在高負(fù)荷之下也是如此。 不過在處理巨大的寫入載入時，RDB 可以提供更有保證的最大延遲時間（latency）
到此我們學(xué)完了 Redis 的持久化方式 RDB 和AOF 。那么我們對比一下。整理出如下表格：
| RDB | AOF | |
| 啟動優(yōu)先級 | 低 | 高 |
| 體積 | 比 AOF 小 | 比 RDB 大 |
| 恢復(fù)速度 | 比 AOF 快 | 比 RDB 慢 |
| 數(shù)據(jù)安全性 | 在定時備份時可能會丟失一定量的數(shù)據(jù) | 根據(jù)同步策略決定，相對更安全 |
| 數(shù)據(jù)一致性 | RDB 持久化的數(shù)據(jù)可能不是最新的，但數(shù)據(jù)一致性較高 | AOF 持久化的數(shù)據(jù)較新，但數(shù)據(jù)一致性較低 |
| 運(yùn)維復(fù)雜度 | 相對簡單，只需要定期備份 RDB 文件即可 | 相對復(fù)雜，需要配置 AOF 緩沖區(qū)大小、同步策略等參數(shù) |
| 寫入性能 | 相對較高，因?yàn)?RDB 只需要生成一次快照文件即可完成持久化操作 | 相對較低，因?yàn)?AOF 需要將每一次寫操作都寫入到 AOF 文件中 |
| 讀取性能 | 相對較高，因?yàn)?RDB 文件讀取速度快 | 相對較低，因?yàn)樾枰獙?AOF 文件中的所有寫操作都執(zhí)行一遍才能恢復(fù) |
| 文件格式 | 二進(jìn)制格式，比較緊湊 | 文本格式，可讀性好 |
| 恢復(fù)方式 | 通過加載 RDB 文件來恢復(fù)數(shù)據(jù)庫 | 通過加載 AOF 文件并執(zhí)行其中的寫操作來恢復(fù)數(shù)據(jù)庫 |
| 文件重寫方式 | 通過 BGSAVE 命令生成新的 RDB 文件來實(shí)現(xiàn)文件重寫 | 通過執(zhí)行 BGREWRITEAOF 命令來生成新的 AOF 文件實(shí)現(xiàn)文件重寫 |
2. RDB和AOF混合方式
Redis 4.0 中提出了一個混合使用 AOF 日志和內(nèi)存快照的方法。簡單來說，內(nèi)存快照以一定的頻率執(zhí)行，在兩次快照之間，使用 AOF 日志記錄這期間的所有命令操作。
混合方式可以同時利用 RDB 的快速恢復(fù)和 AOF 的數(shù)據(jù)安全性。在這種混合方式下，Redis 會同時生成 RDB 文件和 AOF 文件，來保證數(shù)據(jù)的安全性和可靠性。
具體來說，可以采用如下的持久化配置：
將 AOF 模式設(shè)置為 always，并設(shè)置合適的同步策略，以確保 Redis 在執(zhí)行寫操作時，都將對應(yīng)的操作寫入 AOF 文件中。
在 Redis 中啟用 RDB 持久化，并設(shè)置一個合適的持久化間隔，以確保 Redis 在每隔一定時間內(nèi)，執(zhí)行一次 RDB 文件的快照生成操作。
將 Redis 配置為在啟動時，先嘗試使用 AOF 文件進(jìn)行恢復(fù)，如果 AOF 文件不存在或損壞，則使用 RDB 文件進(jìn)行恢復(fù)。
通過這種方式，可以將 RDB 和 AOF 的優(yōu)點(diǎn)結(jié)合起來，從而達(dá)到更加全面的數(shù)據(jù)保護(hù)和恢復(fù)能力。同時也需要注意，這種方式會帶來一定的存儲和性能開銷，需要根據(jù)實(shí)際情況進(jìn)行權(quán)衡和優(yōu)化。
參考 AOF文章來源：http://www.zghlxwxcb.cn/news/detail-803995.html
3 .AOF 持久化實(shí)踐
這個和上一篇一樣，后面研究一下如何在本地能啟動多個redis然后再補(bǔ)充如何實(shí)戰(zhàn)文章來源地址http://www.zghlxwxcb.cn/news/detail-803995.html
到了這里，關(guān)于【征服redis8】Redis的AOF持久化的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
