原理

在學(xué)習(xí)AOF原理前，我們首先要了解 RESP （Redis的序列化協(xié)議）

從圖中可以看到客戶端在調(diào)用redis服務(wù)端時(shí)，傳入的命令和 key、value 都會(huì)通過 RESP 協(xié)議序列化為文本。AOF文件中存儲(chǔ)的就是序列化后的reids命令。

AOF同步和RDB類似之處在于都是采用fork進(jìn)程來處理：

通過這張圖，我們知道了Redis是將客戶端傳入的命令直接寫入AOF文件的，那如果同一個(gè)key原本值是0，然后改為1，最后在改為2，如果每一條命令都記錄不僅毫無意義，同時(shí)會(huì)使得AOF文件越來越大，所以 Redis 在這塊有一個(gè)小優(yōu)化。

AOF重寫（優(yōu)化AOF文件）

set s1 11
set s1 22

上面的操作，如果沒有優(yōu)化之前AOF文件是會(huì)將這兩個(gè)命令按照RESP序列化后存儲(chǔ)，如果優(yōu)化后，則只存儲(chǔ)后面一條命令即 set s1 22，同一個(gè)key的值被覆蓋了，只存儲(chǔ)最終結(jié)果。

重寫過程分析

那如果做到同一個(gè)key在AOF文件中只存儲(chǔ)最新的值呢？不可能每一次寫入文件前去檢查一遍刪除之前這個(gè)key的值吧，這樣做效率肯定賊低，我們來看看Redis是怎么做的？

Redis 其實(shí)是會(huì)定期新創(chuàng)建一個(gè) AOF 文件，然后做 AOF 文件的重寫優(yōu)化，在創(chuàng)建新 AOF 文件的過程中，會(huì)繼續(xù)將命令追加到現(xiàn)有的 AOF 文件里面，即使重寫過程中發(fā)生停機(jī)，現(xiàn)有的 AOF 文件也不會(huì)丟失。而一旦新 AOF 文件創(chuàng)建完畢， Redis 就會(huì)從舊 AOF 文件切換到新 AOF 文件，并開始對(duì)新 AOF 文件進(jìn)行追加操作。

這個(gè)操作不得不說還是玩的66的！大寫的服。

優(yōu)化的觸發(fā)條件：

那上面說的定期重建 AOF 文件具體的時(shí)機(jī)是啥時(shí)候呢？答案也在配置文件 redis.conf 中，需要如下的配置即可，我已經(jīng)寫了注釋，你一眼就能看懂的。

# 表示當(dāng)前aof文件大小超過上一次aof文件大小的百分之多少的時(shí)候會(huì)進(jìn)行重寫。如果之前沒有重寫過，以啟動(dòng)時(shí)aof文件大小為準(zhǔn)
auto-aof-rewrite-percentage 100
# 限制允許重寫最小aof文件大小，也就是文件大小小于64mb的時(shí)候，不需要進(jìn)行優(yōu)化
auto-aof-rewrite-min-size 64mb