Redis持久化AOF原理學習

原理

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

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

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

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

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

set s1 11
set s1 22

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

重寫過程分析

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

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

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

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

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

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