在競(jìng)爭(zhēng)激烈的技術(shù)求職面試中，Redis作為高性能的鍵值對(duì)數(shù)據(jù)庫(kù)，是眾多面試官重點(diǎn)考察的知識(shí)領(lǐng)域，而其中的AOF（Append - Only File）機(jī)制更是高頻考點(diǎn)。Redis AOF 功能為數(shù)據(jù)持久化提供了一種可靠且易于理解的方式，圍繞它產(chǎn)生了一系列既能考查面試者對(duì)基礎(chǔ)知識(shí)的掌握，又能檢驗(yàn)其對(duì)復(fù)雜實(shí)際場(chǎng)景應(yīng)對(duì)能力的面試題。

無論是初入職場(chǎng)渴望嶄露頭角的技術(shù)新人，還是經(jīng)驗(yàn)豐富尋求新挑戰(zhàn)的開發(fā)者，深入理解Redis AOF相關(guān)面試題都是成功通過面試的關(guān)鍵一步。這篇文章，將成為你攻克Redis AOF面試題的得力助手，我們將全方位、多角度地梳理常見面試題，不僅給出標(biāo)準(zhǔn)答案，更會(huì)深入剖析解題思路和背后的原理知識(shí)，助你在面試中自信應(yīng)對(duì)，脫穎而出。

一、詳解AOF基礎(chǔ)知識(shí)點(diǎn)

1. AOF技術(shù)簡(jiǎn)介

AOF（Append-Only File）用于將Redis服務(wù)器收到的寫操作追加到日志文件，通過該機(jī)制可以保證服務(wù)器重啟后依然可以依靠日志文件恢復(fù)數(shù)據(jù)。 它的工作過程大抵分為以下幾步：

• 收到客戶端的寫入命令(例如SET、DEL等)之后，它會(huì)將命令寫入AOF緩沖區(qū)。
• redis服務(wù)器會(huì)定期或者在特定條件下，將AOF緩沖區(qū)的數(shù)據(jù)以追加的方式寫到日志文件末尾，這種寫入的操作可以是同步的，也可以是異步的，具體看我們配置的刷盤機(jī)制。
• 若日志文件超過配置文件的大小(由配置參數(shù) auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 決定)，則會(huì)觸發(fā)AOF重寫(AOF Rewrite)，重寫時(shí)會(huì)啟動(dòng)一個(gè)后臺(tái)進(jìn)程，分析日志中的指令并精簡(jiǎn)化寫入新的AOF文件中。
• 新的AOF文件和舊的AOF文件進(jìn)行原子替換，后續(xù)的寫指令都會(huì)寫到這個(gè)新的AOF文件中。

2. AOF持久化技術(shù)的優(yōu)缺點(diǎn)

優(yōu)勢(shì)：

• 客戶端操作的指令可能會(huì)出錯(cuò)，采用寫后再日志的形式可以避免很多沒必要的日志記錄，節(jié)約磁盤空間
• 寫日志需要進(jìn)行磁盤IO，可能會(huì)產(chǎn)生阻塞，所以采用先寫入再日志，可以避免寫時(shí)阻塞。

劣勢(shì):

• 有可能在寫操作之后，日志記錄之前服務(wù)器出現(xiàn)宕機(jī)，可能會(huì)造成數(shù)據(jù)丟失
• 當(dāng)主線程磁盤壓力過大，導(dǎo)致寫入磁盤慢，進(jìn)而造成后續(xù)操作阻塞。

3. AOF核心配置參數(shù)

(1) appendonly：若將該參數(shù)設(shè)置為yes，則開啟aof持久化機(jī)制，此時(shí)redis持久化機(jī)制就以aof為主，而非rdb

# 設(shè)置為yes開啟aof
appendonly yes

如下示例所示，我們將該參數(shù)配置為yes后重啟redis服務(wù)端，使用客戶端完成如下操作：

# 設(shè)置三個(gè)key
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> set k3 v3
OK

此時(shí)我們查看aof文件，大小增加了：

[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# find / -name appendonly.aof
/usr/sbin/appendonly.aof
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# find / -name appendonly
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# find / -name appendonly.aof
/usr/sbin/appendonly.aof
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# ll appendonly.aof
-rw-r--r-- 1 root root 110 Aug 26 00:09 appendonly.aof

然后我們?cè)俅问褂每蛻舳藢懭胛募?，可以看到大小又增加了，由此得出我們AOF配置生效了。

# 再次查看aof文件大小，變?yōu)?39，說明aof配置生效
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# ll appendonly.aof
-rw-r--r-- 1 root root 139 Aug 26 00:10 appendonly.aof
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]#

appendfilename ，該參數(shù)決定aof持久化文件的名字，這個(gè)就不多贅述了。 如下所示，這條配置就意味著aof文件名是appendonly

appendfilename "appendonly.aof"

(2) dir ：該參數(shù)決定aof文件持久化位置，默認(rèn)為redis-server的位置。

dir ./

(3) appendfsync(重點(diǎn)) : 在介紹appendfsync，我們必須介紹一下操作系統(tǒng)提供的兩個(gè)函數(shù)

• write：write操作會(huì)觸發(fā)操作系統(tǒng)延遲寫機(jī)制，這種機(jī)制下數(shù)據(jù)一寫到緩存區(qū)就直接返回，至于什么時(shí)候進(jìn)行刷盤由操作系統(tǒng)決定，要么緩存空間滿了刷，要么就是定時(shí)任務(wù)時(shí)間到了。
• fsync:該調(diào)用會(huì)強(qiáng)制將緩存寫入磁盤中，所以使用這個(gè)函數(shù)進(jìn)行文件寫入時(shí)，可能存在阻塞問題。

了解了上述兩個(gè)函數(shù)之后，我們?cè)賮砹牧倪@個(gè)參數(shù)值:

• always:該選項(xiàng)會(huì)使得命令一旦寫入aof_buf后，就會(huì)調(diào)用操作系統(tǒng)的fsync將指令寫到aof物理文件中，完成操作后線程返回
• everysec:該選項(xiàng)會(huì)在命令寫入aof_buf后調(diào)用操作系統(tǒng)的wirte，完成write后線程返回。fsync會(huì)由專門的線程每秒調(diào)用一次
• no:該選項(xiàng)會(huì)在命令寫入aof_buf后調(diào)用操作系統(tǒng)的write，完成write后線程返回，不調(diào)用fsync，同步操作由操作系統(tǒng)執(zhí)行，最長(zhǎng)周期為30s。

所以配置時(shí)，我們建議采用默認(rèn)的寫入策略everysec，他不會(huì)像always造成線程阻塞亦或者像no一樣不可控。

appendfsync everysec

(4) no-appendfsync-on-rewrite：redis為了保證持久化aof文件時(shí)調(diào)用fsync時(shí)不會(huì)出現(xiàn)長(zhǎng)時(shí)間的卡頓，增加了該參數(shù)，若設(shè)置為yes，在redis調(diào)用fsync期間出現(xiàn)的寫入指令不會(huì)將其放到頁(yè)緩存(page cache)中，僅僅做個(gè)接收，保證不阻塞。

no-appendfsync-on-rewrite yes

(5) auto-aof-rewrite-percentage和auto-aof-rewrite-min-size(重點(diǎn))：這兩個(gè)參數(shù)決定redis何時(shí)進(jìn)行重寫，如下所示，這兩個(gè)參數(shù)分別為100和64mb，意味當(dāng)本次aof文件超過64+64*100%就觸發(fā)redis自動(dòng)重寫。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

(6) aof-load-truncated：若設(shè)置為yes時(shí)在redis加載aof文件出錯(cuò)后會(huì)發(fā)送日志通知用戶，反之則不做任何處理也不會(huì)啟動(dòng)redis，用戶可以使用redis-check-aof指令完成數(shù)據(jù)修復(fù)。 這個(gè)參數(shù)筆者會(huì)在后文演示。

aof-load-truncated yes

(7) aof-rewrite-incremental-fsync：開啟該參數(shù)后，子進(jìn)程在進(jìn)行aof重寫時(shí)，每32m就會(huì)將數(shù)據(jù)寫到的新的aof文件中，從而避免單刷造成的線程阻塞。

aof-rewrite-incremental-fsync yes

(8) aof-use-rdb-preamble：redis 4.0之后支持同時(shí)開啟rdb和aof，具體后文會(huì)詳述

# rdb+aof兩種機(jī)制結(jié)合使用
aof-use-rdb-preamble yes

4. AOF斷電后恢復(fù)的過程是什么

我們?cè)谥暗腶of文件重命名，模擬斷電后數(shù)據(jù)丟失，首先將aof文件備份，在重啟redis，模擬斷電后數(shù)據(jù)丟失

[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# mv appendonly.aof appendonly.aof.bak


# 重啟redis服務(wù)端，打開客戶端查看數(shù)據(jù)都丟失了
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-cli
127.0.0.1:6379> auth 123
OK
127.0.0.1:6379> keys *
(empty array)

然后將備份文件還原，重啟redis。

# 將aof文件還原，并重啟redis
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# mv appendonly.aof.bak appendonly.aof
mv: overwrite ‘a(chǎn)ppendonly.aof’? y
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-server /root/redis/redis.conf

可以看到，數(shù)據(jù)已經(jīng)回來了。

# 再次使用redis查看，丟失的數(shù)據(jù)都回來了
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-cli
127.0.0.1:6379> auth 123
OK
127.0.0.1:6379> keys *
1) "k4"
2) "k3"
3) "k2"
4) "k1"
127.0.0.1:6379>

二、詳解AOF持久化技術(shù)進(jìn)階知識(shí)點(diǎn)

1. AOF重寫時(shí)是否會(huì)阻塞線程

答案是會(huì)的，但阻塞大部分情況是發(fā)生在fork子進(jìn)程那段時(shí)間，AOF重寫時(shí)首先會(huì)fork一個(gè)子進(jìn)程進(jìn)行日志重寫，在此期間新寫入的數(shù)據(jù)都會(huì)被存到的AOF緩沖區(qū)中，直到子進(jìn)程全部完成重寫并原子覆蓋aof日志文件后，才會(huì)將這些緩沖數(shù)據(jù)寫到新的日志文件中：

需要補(bǔ)充的是，上面提到日志重寫期間數(shù)據(jù)都會(huì)被寫到AOF緩沖區(qū)中，在高并發(fā)場(chǎng)景下也可能導(dǎo)致內(nèi)存被打滿出現(xiàn)頻繁內(nèi)存置換等情況間接導(dǎo)致我們的redis進(jìn)程阻塞，此時(shí)就可能出現(xiàn)讀寫性能下降的情況：

2. Redis重啟后加載日志文件的順序

執(zhí)行順序?yàn)?

• 先看看有沒有AOF，若有則先加載AOF，然后執(zhí)行步驟2。
• 查看是否有RDB文件，若有再加載RDB文件。

3. Redis恢復(fù)數(shù)據(jù)期間文件校驗(yàn)是怎么做

在日志寫入期間要是服務(wù)器宕機(jī)了，那么這個(gè)日志文件可能就用不了了，而解決方案也很可能簡(jiǎn)單，redis給我提供一個(gè)命令進(jìn)行fix。

例子如下，我們首先需要將一個(gè)日志文件損壞:

# 追加一個(gè)錯(cuò)誤數(shù)據(jù)到aof文件末行并殺死redis 模擬服務(wù)器宕機(jī)
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# vim appendonly.aof


# 再次啟動(dòng)redis，操作數(shù)據(jù)時(shí)發(fā)現(xiàn)登錄失敗
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-server /root/redis/redis.conf
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-cli
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected>

然后使用日志文件進(jìn)行修復(fù)：

#  使用 redis-check-aof --fix aof文件 修復(fù)文件
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-check-aof --fix appendonly.aof
0x              8b: Expected prefix '*', got: 's'
AOF analyzed: size=151, ok_up_to=139, ok_up_to_line=34, diff=12
This will shrink the AOF from 151 bytes, with 12 bytes, to 139 bytes
# 這里選擇y
Continue? [y/N]: y
Successfully truncated AOF

可以看到，經(jīng)過fix修復(fù)后的日志文件部分?jǐn)?shù)據(jù)已經(jīng)恢復(fù)了：

# 重啟redis，使用客戶端連接發(fā)現(xiàn)啟動(dòng)成功且數(shù)據(jù)都還在
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-server /root/redis/redis.conf
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-cli

127.0.0.1:6379> keys *
1) "k4"
2) "k3"
3) "k2"
4) "k1"

4. AOF相較于RDB持久化的優(yōu)勢(shì)

優(yōu)勢(shì)如下:

• 備份機(jī)制更穩(wěn)健，丟失數(shù)據(jù)幾率低。
• 日志可讀，可以處理誤操作。

而劣勢(shì)也很明顯:

• 比RDB更占磁盤空間,畢竟RDB存放的不是二進(jìn)制文件。
• 每次AOF都進(jìn)行fsync的話，性能開銷大。
• 恢復(fù)和備份速度較慢。

5. Redis混合持久化

Redis4.0實(shí)現(xiàn)了RDB和AOF混合方式，相比于單RDB或者單AOF更安全，執(zhí)行效率更高，它的執(zhí)行過程大抵如下：

• 初始狀態(tài)下，寫入的指令都會(huì)以AOF格式寫入aof文件中。
• 當(dāng)發(fā)生AOF重寫時(shí)(bgrewriteaof )，redis會(huì)fork出一個(gè)子進(jìn)程，進(jìn)行aof重寫。
• redis將重寫的數(shù)據(jù)以rdb的數(shù)據(jù)寫到新的aof文件中。
• 隨后再將aof緩沖區(qū)的增量命令（aof_rewrite_buf_blocks）寫到新的aof文件中。
• 完成上述操作后我們就會(huì)得到一個(gè)前半部分是RDB后半部分是AOF的aof日志文件。
• 最后將新的aof文件替換掉舊的rdb和aof文件。

對(duì)應(yīng)的重啟后的加載流程也改為：

• 判斷持久化格式，如果是rdb格式則按照rdb格式進(jìn)行恢復(fù)，反之按照aof格式格式進(jìn)行恢復(fù)進(jìn)入步驟2。
• 查看aof文件文件是否存在，若存在進(jìn)入步驟3。
• 查看文件前半部分是否是RDB如果是則先按照rdb格式恢復(fù)，然后再按照aof格式恢復(fù)。
• 若沒有rdb開頭格式的內(nèi)容，直接按照常規(guī)aof格式恢復(fù)。