AOF是什么？
AOF是redis持久化的策略之一。
它以日志的形式來記錄每個(gè)redis的寫操作，將redis執(zhí)行過的所有寫指令記錄下來（讀操作不記錄），并且它只允許往文件追加內(nèi)容，而不可以改寫文件。
redis在啟動(dòng)時(shí)，會(huì)讀取該文件重新構(gòu)建數(shù)據(jù)。也就是，redis重啟時(shí)，會(huì)根據(jù)AOF日志文件的內(nèi)容將寫指令從頭到尾執(zhí)行一次，來完成數(shù)據(jù)的恢復(fù)工作
AOF保存的是appendonly.aof文件，redis.conf配置中，默認(rèn)是no，不開啟
配置
查看Redis配置中的第8點(diǎn)：APPEND ONLY MODE/追加
AOF啟動(dòng)/修復(fù)/恢復(fù)
- 啟動(dòng)
啟動(dòng)：redis.conf文件中，把appendonly.aof no改成為yes - 正?；謴?fù)（aof文件正常）
1.首先已經(jīng)啟動(dòng)了aof策略
2.把有數(shù)據(jù)的aof文件復(fù)制一份保存到redis的啟動(dòng)目錄config get dir
3.重啟redis，redis會(huì)主動(dòng)讀取aof文件恢復(fù)數(shù)據(jù)
注意.如果aof文件已損壞，那么在redis-cli啟動(dòng)時(shí)就會(huì)報(bào)錯(cuò)，比如Could not connect tot Redis at 127.0.0.1:6379: Connection refused
- 異?；謴?fù)（aof文件已損壞）
1.首先已經(jīng)啟動(dòng)了aof策略
2.備份此時(shí)損壞的aof文件（以防以后可能需要）
3.cd到redis根目錄，找到redis-check-aof腳本；執(zhí)行修復(fù)命令：redis-check-aof --fix appendonly.aof進(jìn)行修復(fù)
4.重啟redis，redis會(huì)主動(dòng)讀取aof文件恢復(fù)數(shù)據(jù)
rewrite/重寫
1、是什么？
由于AOF采用文件內(nèi)容追加的方式，隨著時(shí)間的增長，文件肯定會(huì)越來越大。為了避免出現(xiàn)這種情況，新增了rewrite/重寫機(jī)制。
也就是當(dāng)AOF文件的大小超過所設(shè)定的闕值時(shí)，redis2.4以后，就會(huì)自動(dòng)對AOF文件的內(nèi)容壓縮，只保留可以恢復(fù)數(shù)據(jù)的最小指令集。但是也可以使用命令bgrewriteaof來手動(dòng)啟動(dòng)。
2、觸發(fā)機(jī)制
Redis會(huì)記錄上次重寫時(shí)的AOF大小，默認(rèn)配置是當(dāng)AOF文件大小是上次rewrite后大小的一倍且文件大于64M時(shí)觸發(fā)（實(shí)際應(yīng)用肯定會(huì)調(diào)大這個(gè)值）
3、重寫原理
- 在redis2.4以后，當(dāng)AOF文件持續(xù)增長而過大，達(dá)到設(shè)定的闕值時(shí)，redis會(huì)自動(dòng)fork一條新進(jìn)程來講aof文件進(jìn)行重寫，會(huì)遍歷新進(jìn)程的內(nèi)存中數(shù)據(jù)，每條記錄都有一條set語句。（采用先寫個(gè)臨時(shí)文件，最后再rename的方式）
- 重寫aof文件的操作，并沒有讀取舊的aof文件，而是將整個(gè)內(nèi)存中的數(shù)據(jù)庫內(nèi)容用命令的方式重寫了一個(gè)新的aof文件（但是體積會(huì)比之前的?。涂煺沼行╊愃?/li>
- redis2.4以后，也可以使用
bgrewriteaof來手動(dòng)啟動(dòng)重寫 - 即使重寫執(zhí)行失敗，也不會(huì)有任何數(shù)據(jù)丟失，因?yàn)榕f的AOF文件在
bgrewriteaof成功之前不會(huì)被修改。
優(yōu)勢
有三種同步策略可選
- 每次修改都同步：
appendfsync always
同步持久化，每次發(fā)生數(shù)據(jù)變更會(huì)被立即記錄到磁盤 性能較差但數(shù)據(jù)完整性比較好 - 每秒都同步：
appendfsync everysec
異步操作每秒記錄，如果一秒內(nèi)宕機(jī)，那么會(huì)有數(shù)據(jù)丟失 - 不同步：
appendfsync no
不進(jìn)行aof同步
劣勢
- 相同數(shù)據(jù)集的數(shù)據(jù)而言aof文件要遠(yuǎn)大于rdb文件，恢復(fù)速度慢于rdb
- Aof運(yùn)行效率要慢于rdb，每秒同步策略效率較好，不同步效率和rdb相同
appendonly.aof和dump.rdb共存
如果appendonly.aof和dump.rdb共存，那么在恢復(fù)數(shù)據(jù)時(shí)，會(huì)先讀取appendonly.aof
小總結(jié)
