一文了解：Redis的AOF持久化

每當Redis-Server接收到寫數據時，就把命令以文本形式追加到AOF文件裏，當重啓Redis服務時，AOF文件裏的命令會被從新執行一次，從新恢復數據。當AOF過大時將重寫AOF文件。

工做原理

> lpush list 1 2 3 4
(integer) 4
127.0.0.1:6379> lrange list 0 -1
1) "4"
2) "3"
3) "2"
4) "1"
127.0.0.1:6379> lpop list
"4"
127.0.0.1:6379> lrange list 0 -1
1) "3"
2) "2"
3) "1"
複製代碼

appendonly.aof文件中

*2
$6
SELECT
$1
0
*6
$5
lpush
$4
list
$1
1
$1
2
$1
3
$1
4
*2
$4
lpop
$4
list
複製代碼

能夠看到上面的示例中寫操做有lpush和lpop命令，在AOF文件中存在lpush和lpop。SELECT命令爲AOF程序自動加上的選擇數據庫。

AOF命令寫入的內容爲文本協議格式，如：命令lpush list 1 2 3 4 的文本形式爲"*6\r\n$5\r\nlpushr\n$4r\nlist\r\n$1\r\n1$1\r\n2$1\r\n3$1\r\n4\r\n"。將文本內容追加到aof_buf(緩衝區)中，AOF緩衝區根據相應的策略同步寫入AOF文件中，當AOF文件愈來愈大時，將AOF文件重寫。

啓動AOF持久化

在redis.conf文件中

appendonly no  #寫成yes，打開AOF持久化
複製代碼

AOF寫入頻率

# appendfsync always 
appendfsync everysec   # 默認
# appendfsync no
複製代碼

1. alaws：老是同步到AOF文件，每個命令都寫入，安全，速度慢
2. everysec：每秒寫入一次，安全性好，最多丟失1秒鐘的數據
3. no：寫入AOF文件工做交給操做系統，由操做系統寫入AOF文件，安全性通常

文件

aof文件目錄經過RDB文件目錄，他們共享同一個目錄

dir ./

appendfilename "appendonly.aof"
複製代碼

經過config set dir {newDir} 動態修改dir配置

經過config set dbfilename {appendfilename} 動態修改AOF文件名稱

重寫

AOF文件過大時，Redis將fork()一個子進程對內存數據進行比那裏逆化成Redis命令，序列化文本格式後寫入到新的AOF文件中。而後將重寫時發生的增量AOF文件追加到新的AOF文件中，最後替換舊的AOF文件。

自動重寫

auto-aof-rewrite-percentage 100  # 比上次重寫時文件增大了100%就重寫AOF文件
auto-aof-rewrite-min-size 64mb   # AOF文件至少超過爲64M時重寫AOF文件
複製代碼

自動重寫必須知足：當前AOF文件大小 > auto-aof-rewrite-min-size &&（當前文件AOF文件大小減去上次重寫時AOF文件大小）除以 上次重寫時AOF文件大小 = auto-aof-rewrite-percentage

手動重寫

> bgrewriteaof
Background append only file rewriting started
複製代碼

優缺點

優勢

1. 比RDB文件可靠，everysec模式下只丟1秒數據。
2. AOF文件爲純文本文件。文件協議格式容易恢復成Redis命令。
3. AOF文件太大會進行自動重寫。

缺點

1. 同等數據下，比RDB文件大。
2. 同步過程當中Redis主進程會被阻塞，everysec是個折中方案。

數據恢復

Redis讀取AOF文件數據還原過程

1. 建立一個不帶網絡的客戶端
2. 讀取AOF文件內容，還原成命令
3. 將命令在1中的客戶端執行
4. 重複2，3的過程

結語

本人深知水平有限，歡迎指正本文錯誤之處。

---