基礎面試題

什么是AOF

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

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

AOF寫后記錄日志有哪些優(yōu)劣

有如下幾個優(yōu)勢：

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

當然劣勢也很明顯:

• 有可能在寫操作之后，日志記錄之前服務器出現宕機，可能會造成數據丟失
• 當主線程磁盤壓力過大，導致寫入磁盤慢，進而造成后續(xù)操作阻塞。

AOF核心配置參數有哪些

• appendonly :若將該參數設置為yes，則開啟aof持久化機制，此時redis持久化機制就以aof為主，而非rdb

# 設置為yes開啟aof
appendonly yes

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

# 設置三個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
127.0.0.1:6379>

此時我們查看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

然后我們再次使用客戶端寫入文件

# 再次使用redis客戶端寫入指令
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-cli
127.0.0.1:6379> set test vv
(error) NOAUTH Authentication required.
127.0.0.1:6379> auth 123
OK
127.0.0.1:6379> set k4 v4
OK
127.0.0.1:6379>

可以看到大小又增加了，由此得出我們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 ，該參數決定aof持久化文件的名字，這個就不多贅述了。 如下所示，這條配置就意味著aof文件名是appendonly

appendfilename "appendonly.aof"

dir ：該參數決定aof文件持久化位置，默認為redis-server的位置。

dir ./

appendfsync : 在介紹appendfsync，我們必須介紹一下操作系統(tǒng)提供的兩個函數

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

了解了上述兩個函數之后，我們再來聊聊這個參數值:

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

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

 appendfsync everysec

no-appendfsync-on-rewrite:redis為了保證持久化aof文件時調用fsync時不會出現長時間的卡頓，增加了該參數，若設置為yes，在redis調用fsync期間出現的寫入指令不會將其放到頁緩存(page cache)中，僅僅做個接收，保證不阻塞。

no-appendfsync-on-rewrite yes

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

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

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

aof-load-truncated yes

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

aof-rewrite-incremental-fsync yes

aof-use-rdb-preamble：redis 4.0之后支持同時開啟rdb和aof，具體后文會詳述

# rdb+aof兩種機制結合使用
aof-use-rdb-preamble yes

AOF斷電后恢復的過程是什么

我們在之前的aof文件重命名，模擬斷電后數據丟失，首先將aof文件備份，在重啟redis，模擬斷電后數據丟失

[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# mv appendonly.aof appendonly.aof.bak
# 重啟redis服務端，打開客戶端查看數據都丟失了
[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 ‘appendonly.aof'? y
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-server /root/redis/redis.conf

可以看到，數據已經回來了。

# 再次使用redis查看，丟失的數據都回來了
[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重寫機制如何壓縮文件體積

如下圖所示，可以看到重寫時會查看進程內是否存在過期數據，如果數據過期則這個指令的操作也會被移除。
再一個我們之前可以存在對某個集合的元素添加操作，在重寫時會將這些添加指令壓縮成一條指令。

AOF重寫時是否會阻塞線程

答案是會的，但阻塞僅僅發(fā)生在fork子進程那段時間，如下圖所示，AOF重寫時首先會fork一個子進程進行日志重寫，在此期間新寫入的數據都會被存到的AOF緩沖區(qū)中，直到子進程全部完成重寫并原子覆蓋aof日志文件后，才會將這些緩沖數據寫到新的日志文件中。
需要補充的是，上面提到日志重寫期間數據都會被寫到AOF緩沖區(qū)中，在高并發(fā)場景下很可能導致內存被大量占用進而導致進程阻塞，所以Redis借由Linux管道技術使得在AOF日志重寫期間的新增的數據照樣可以寫入到新文件中。

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

執(zhí)行順序為:

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

Redis恢復數據期間文件校驗是怎么做

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

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

# 追加一個錯誤數據到aof文件末行并殺死redis 模擬服務器宕機
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# vim appendonly.aof
# 再次啟動redis，操作數據時發(fā)現登錄失敗
[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>

然后使用日志文件進行修復

#  使用 redis-check-aof --fix aof文件 修復文件
[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

可以看到，經過fix修復后的日志文件部分數據已經恢復了

# 重啟redis，使用客戶端連接發(fā)現啟動成功且數據都還在
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-server /root/redis/redis.conf
[root@iZ8vb7bhe4b8nhhhpavhwpZ sbin]# redis-cli
127.0.0.1:6379> auth 123
OK
OK
127.0.0.1:6379> keys *
1) "k4"
2) "k3"
3) "k2"
4) "k1"

AOF有哪些優(yōu)劣勢

優(yōu)勢如下:

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

而劣勢也很明顯:

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

redis混合持久化

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

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

參考文獻

面試必問的 Redis：RDB、AOF、混合持久化:https://zhuanlan.zhihu.com/p/340082703

《Redis開發(fā)與運維》:https://book.douban.com/subject/26971561/

到此這篇關于Redis持久化AOF詳解的文章就介紹到這了,更多相關Redis持久化AOF內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論