Redis持久化--AOF

Redis 提供了2個不同形式的持久化方式。

RDB Redis DataBase

AOF A ppend Of File

Redis持久化分為RDB持久化和AOF持久化：前者將當前數據保存到硬盤，后者則是將每次執行的寫命令保存到硬盤（類似于MySQL的binlog）；由于AOF持久化的實時性更好，即當進程意外退出時丟失的數據更少，因此AOF是目前主流的持久化方式， 不過RDB持久化仍然有其用武之地

AOF

是什么

以日志的形式來記錄每個寫操作（增量保存），將Redis執行過的所有寫指令記錄下來(讀操作不記錄)， 只許追加文件但不可以改寫文件，redis啟動之初會讀取該文件重新構建數據，換言之，redis 重啟的話就根據日志文件的內容將寫指令從前到后執行一次以完成數據的恢復工作

AOF持久化流程

（1）客戶端的請求寫命令會被append追加到AOF緩沖區內；

（2）AOF緩沖區根據AOF持久化策略[always,everysec,no]將操作sync同步到磁盤的AOF文件中；

（3）AOF文件大小超過重寫策略或手動重寫時，會對AOF文件rewrite重寫，壓縮AOF文件容量；

（4）Redis服務重啟時，會重新load加載AOF文件中的寫操作達到數據恢復的目的；

AOF默認不開啟

可以在redis.conf中配置文件名稱，默認為 appendonly.aof

AOF文件的保存路徑，同RDB的路徑一致。

AOF和RDB同時開啟，redis聽誰的？

AOF和RDB同時開啟，系統默認取AOF的數據（數據不會存在丟失）

AOF啟動/修復/恢復

AOF的備份機制和性能雖然和RDB不同, 但是備份和恢復的操作同RDB一樣，都是拷貝備份文件，需要恢復時再拷貝到Redis工作目錄下，啟動系統即加載。

正常恢復

n 修改默認的appendonly no，改為yes

n 將有數據的aof文件復制一份保存到對應目錄(查看目錄：config get dir)

n 恢復：重啟redis然后重新加載

異常恢復

n 修改默認的appendonly no，改為yes

n 如遇到AOF文件損壞，通過/usr/local/bin/redis-check-aof--fix appendonly.aof進行恢復

n 備份被寫壞的AOF文件

n 恢復：重啟redis，然后重新加載

AOF同步頻率設置

appendfsync always

始終同步，每次Redis的寫入都會立刻記入日志；性能較差但數據完整性比較好

appendfsync everysec

每秒同步，每秒記入日志一次，如果宕機，本秒的數據可能丟失。

appendfsync no

redis不主動進行同步，把同步時機交給操作系統。

Rewrite壓縮

1是什么：

AOF采用文件追加方式，文件會越來越大為避免出現此種情況，新增了重寫機制, 當AOF文件的大小超過所設定的閾值時，Redis就會啟動AOF文件的內容壓縮， 只保留可以恢復數據的最小指令集.可以使用命令bgrewriteaof

2重寫原理，如何實現重寫

AOF文件持續增長而過大時，會fork出一條新進程來將文件重寫(也是先寫臨時文件最后再rename)，redis4.0版本后的重寫，是指上就是把rdb 的快照，以二級制的形式附在新的aof頭部，作為已有的歷史數據，替換掉原來的流水賬操作。

no-appendfsync-on-rewrite：

如果no-appendfsync-on-rewrite=yes ,不寫入aof文件只寫入緩存，用戶請求不會阻塞，但是在這段時間如果宕機會丟失這段時間的緩存數據。（降低數據安全性，提高性能）

如果no-appendfsync-on-rewrite=no, 還是會把數據往磁盤里刷，但是遇到重寫操作，可能會發生阻塞。（數據安全，但是性能降低）

觸發機制，何時重寫

Redis會記錄上次重寫時的AOF大小，默認配置是當AOF文件大小是上次rewrite后大小的一倍且文件大于64M時觸發

重寫雖然可以節約大量磁盤空間，減少恢復時間。但是每次重寫還是有一定的負擔的，因此設定Redis要滿足一定條件才會進行重寫。

auto-aof-rewrite-percentage：設置重寫的基準值，文件達到100%時開始重寫（文件是原來重寫后文件的2倍時觸發）

auto-aof-rewrite-min-size：設置重寫的基準值，最小文件64MB。達到這個值開始重寫。

例如：文件達到70MB開始重寫，降到50MB，下次什么時候開始重寫？100MB

系統載入時或者上次重寫完畢時，Redis會記錄此時AOF大小，設為base_size,

如果Redis的AOF當前大小>= base_size +base_size*100% (默認)且當前大小>=64mb(默認)的情況下，Redis會對AOF進行重寫。

3、重寫流程

（1）bgrewriteaof觸發重寫，判斷是否當前有bgsave或bgrewriteaof在運行，如果有，則等待該命令結束后再繼續執行。

（2）主進程fork出子進程執行重寫操作，保證主進程不會阻塞。

（3）子進程遍歷redis內存中數據到臨時文件，客戶端的寫請求同時寫入aof_buf緩沖區和aof_rewrite_buf重寫緩沖區保證原AOF文件完整以及新AOF文件生成期間的新的數據修改動作不會丟失。

（4）1).子進程寫完新的AOF文件后，向主進程發信號，父進程更新統計信息。2).主進程把aof_rewrite_buf中的數據寫入到新的AOF文件。

（5）使用新的AOF文件覆蓋舊的AOF文件，完成AOF重寫。

優勢

n 備份機制更穩健，丟失數據概率更低。

n 可讀的日志文本，通過操作AOF穩健，可以處理誤操作。

劣勢

n 比起RDB占用更多的磁盤空間。

n 恢復備份速度要慢。

n 每次讀寫都同步的話，有一定的性能壓力。

n 存在個別Bug，造成恢復不能。

小總結

總結(Which one)

用哪個好

官方推薦兩個都啟用。

如果對數據不敏感，可以選單獨用RDB。

不建議單獨用AOF，因為可能會出現Bug。

如果只是做純內存緩存，可以都不用。

Redis 任務調度

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。