Redis持久化数据之RDB和AOF
文章目錄
- 一、RDB（Redis DataBase）
- 概述
- 持久化過程
- 配置
- 優勢和劣勢
- 二、AOF（Append Of File）
- 概述
- AOF持久化過程
- AOF 配置
- Rewrite 壓縮
- 優勢和劣勢
- 三、RDB和AOF如何選擇
- 官方建議
Redis由于讀取效率快而常常被用作緩存來使用，之所以讀取的速度非常快，是因為Redis將數據都存儲在內存中，我們大家都知道存儲在內存中的數據最大的特點就是：斷電即丟失，這就容易出現數據不安全的問題。關系型數據庫MySQL就是將數據持久化到磁盤上。那么Redis官方也提供了RDB和AOF兩種方式，可以將數據持久化到磁盤來確保數據的安全性。
官方的截圖一、RDB（Redis DataBase）
概述
在指定的時間間隔內將內存中的數據集快照寫入磁盤， 也就是行話講的Snapshot快照，它恢復時是將快照文件直接讀到內存里。
持久化過程
Redis會單獨創建（fork）一個子進程來進行持久化，會先將數據寫入到 一個臨時文件中，待持久化過程都結束了，再用這個臨時文件替換上次持久化好的文件。 整個過程中，主進程是不進行任何IO操作的，這就確保了極高的性能。如果需要進行大規模數據的恢復，且對于數據恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺點是最后一次持久化后的數據可能丟失。
- Fork的作用是復制一個與當前進程一樣的進程。新進程的所有數據（變量、環境變量、程序計數器等）數值都和原進程一致，但是是一個全新的進程，并作為原進程的子進程
- 在Linux程序中，fork()會產生一個和父進程完全相同的子進程，但子進程在此后多會exec系統調用，出于效率考慮，Linux中引入了“寫時復制技術”
- 一般情況父進程和子進程會共用同一段物理內存，只有進程空間的各段的內容要發生變化時，才會將父進程的內容復制一份給子進程。
配置
- dump.rdb : 使用RDB生成的默認文件名稱
- dir ./ : rdb文件的保存路徑，默認為Redis啟動時命令行所在的目錄下
- stop-writes-on-bgsave-error：當Redis無法寫入磁盤的話，直接關掉Redis的寫操作。
- rdbcompression：對于存儲到磁盤中的快照，可以設置是否進行壓縮存儲。如果是的話，redis會采用LZF算法進行壓縮。如果你不想消耗CPU來進行壓縮的話，可以設置為關閉此功能。
- rdbchecksum ：在存儲快照后，還可以讓redis使用CRC64算法來進行數據校驗，但是這樣做會增加大約10%的性能消耗，如果希望獲取到最大的性能提升，可以關閉此功能
- save：秒鐘 寫操作次數
RDB是整個內存的壓縮過的Snapshot，RDB的數據結構，可以配置復合的快照觸發條件，
默認是1分鐘內改了1萬次，或5分鐘內改了10次，或15分鐘內改了1次。
此處為save配置的一些規則說明（此規則可以進行修改）：
- 3600秒后一個key發生改變進行數據持久化操作
- …
優勢和劣勢
① 優勢：
適合大規模的數據恢復
對數據完整性和一致性要求不高更適合使用
節省磁盤空間
恢復速度快
② 劣勢：
Fork的時候，內存中的數據被克隆了一份，大致2倍的膨脹性需要考慮。
雖然Redis在fork時使用了寫時拷貝技術,但是如果數據龐大時還是比較消耗性能。
在備份周期在一定間隔時間做一次備份，所以如果Redis意外down掉的話，就會丟失最后一次快照后的所有修改。
二、AOF（Append Of File）
概述
以日志的形式來記錄每個寫操作（增量保存），將Redis執行過的所有寫指令記錄下來(讀操作不記錄)， 只許追加文件但不可以改寫文件，redis啟動之初會讀取該文件重新構建數據，換言之，redis 重啟的話就根據日志文件的內容將寫指令從前到后執行一次以完成數據的恢復工作。
AOF持久化過程
AOF 配置
- AOF 默認是不開啟的，需要將其設置為 yes
- 生成默認的文件名
- AOF 文件路徑默認和dump.rdb路徑一致
我們可以看到AOF文件中是沒有數據的，連接上redis客戶端，發現也是沒有數據的。
但是rdm中之前是有數據的。
那么AOF和RDB同時開啟，redis聽誰的？
其實，AOF和RDB同時開啟，系統默認取AOF的數據（數據不會存在丟失）。
- AOF同步頻率設置:
appendfsync always ：始終同步，每次Redis的寫入都會立刻記入日志；性能較差但數據完整性比較好
appendfsync everysec ：每秒同步，每秒記入日志一次，如果宕機，本秒的數據可能丟失。
appendfsync no ：redis不主動進行同步，把同步時機交給操作系統。
Rewrite 壓縮
定義？
AOF采用文件追加方式，文件會越來越大為避免出現此種情況，新增了重寫機制, 當AOF文件的大小超過所設定的閾值時，Redis就會啟動AOF文件的內容壓縮， 只保留可以恢復數據的最小指令集。
重寫原理：
AOF文件持續增長而過大時，會fork出一條新進程來將文件重寫(也是先寫臨時文件最后再rename)，redis4.0版本后的重寫，是指上就是把rdb 的快照，以二級制的形式附在新的aof頭部，作為已有的歷史數據，替換掉原來的流水賬操作。
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。達到這個值開始重寫。
重寫流程：
（2）主進程把aof_rewrite_buf中的數據寫入到新的AOF文件。
優勢和劣勢
① 優勢：
備份機制更穩健，丟失數據概率更低。
可讀的日志文本，通過操作AOF穩健，可以處理誤操作。
② 劣勢：
比起RDB占用更多的磁盤空間。
恢復備份速度要慢。
每次讀寫都同步的話，有一定的性能壓力。
三、RDB和AOF如何選擇
官方建議
使用建議：
- RDB持久化方式能夠在指定的時間間隔能對你的數據進行快照存儲
- AOF持久化方式記錄每次對服務器寫的操作,當服務器重啟的時候會重新執行這些命令來恢復原始的數據,AOF命令以redis協議追加保存每次寫的操作到文件末尾.
- Redis還能對AOF文件進行后臺重寫,使得AOF文件的體積不至于過大
- 只做緩存：如果你只希望你的數據在服務器運行的時候存在,你也可以不使用任何持久化方式.
- 同時開啟兩種持久化方式
- 在這種情況下,當redis重啟的時候會優先載入AOF文件來恢復原始的數據。因為在通常情況下AOF文件保存的數據集要比RDB文件保存的數據集要完整.
- RDB的數據不實時，同時使用兩者時服務器重啟也只會找AOF文件。那要不要只使用AOF呢？
建議不要，因為RDB更適合用于備份數據庫(AOF在不斷變化不好備份)， 快速重啟，而且不會有AOF可能潛在的bug，留著作為一個萬一的手段。
性能建議：
- 因為RDB文件只用作后備用途，建議只在Slave上持久化RDB文件，而且只要15分鐘備份一次就夠了，只保留save 900 1這條規則。
- 如果使用AOF，好處是在最惡劣情況下也只會丟失不超過兩秒數據，啟動腳本較簡單只load自己的AOF文件就可以了。代價,一是帶來了持續的IO，二是AOF rewrite的最后將rewrite過程中產生的新數據寫到新文件造成的阻塞幾乎是不可避免的。
- 只要硬盤許可，應該盡量減少AOF rewrite的頻率，AOF重寫的基礎大小默認值64M太小了，可以設到5G以上。默認超過原大小100%大小時重寫可以改到適當的數值。
本次分享的Redis持久化數據之RDB和AOF到這里就結束了，希望對大家有所幫助！！！
總結
以上是生活随笔為你收集整理的Redis持久化数据之RDB和AOF的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Day16 GUI编程：贪吃蛇
- 下一篇： MySQL从入门到精通