Redis持久化之RDB和AOF
- Redis 有兩種持久化方案,RDB (Redis DataBase)和 AOF (Append Only File);
RDB 詳解
- RDB 是 Redis 默認的持久化方案。在指定的時間間隔內,執行指定次數的寫操作,則會將內存中的數據寫入到磁盤中。即在指定目錄下生成一個dump.rdb文件。Redis 重啟會通過加載dump.rdb文件恢復數據
從配置文件了解RDB
- 打開redis.conf文件,ctrl+f搜索SNAPSHOTTING,查看對應的內容
- RDB核心規則配置(重點)
# save <seconds> <changes> # save <指定時間間隔> <執行指定次數更新操作> # save "" save 900 1 save 300 10 save 60 10000 /* 滿足條件就將內存中的數據同步到硬盤中。官方出廠配置默認是 900秒內有1個更改,300秒內有10個更改以及60秒內有10000個更改,則將內存中的數據快照寫入磁盤。 若不想用RDB方案,可以把 save "" 的注釋打開 */
指定本地數據庫文件名,一般采用默認的sump.rdb
-
指定本地數據庫存放目錄,一般也用默認配置 dir? ./
-
默認開啟數據壓縮?rdbcompression yes:配置存儲至本地數據庫時是否壓縮數據,默認為yes。Redis采用LZF壓縮方式,但占用了一點CPU的時間。若關閉該選項,但會導致數據庫文件變的巨大。建議開啟
- RDB核心規則配置(重點)
觸發RDB快照
- 在指定的時間間隔內,執行指定次數的寫操作
- 執行save(阻塞, 只管保存快照,其他的等待) 或者是bgsave (異步)命令
- 執行flushall 命令,清空數據庫所有數據,意義不大。
- 執行shutdown 命令,保證服務器正常關閉且不丟失任何數據,意義...也不大
通過RDB文件恢復數據
- 將dump.rdb 文件拷貝到redis的安裝目錄的bin目錄下,重啟redis服務即可。在實際開發中,一般會考慮到物理機硬盤損壞情況,選擇備份dump.rdb?
RDB 的優缺點
優點
- 適合大規模的數據恢復。
- 如果業務對數據完整性和一致性要求不高,RDB是很好的選擇。
缺點
-
數據的完整性和一致性不高,因為RDB可能在最后一次備份時宕機了。
-
?備份時占用內存,因為Redis 在備份時會獨立創建一個子進程,將數據寫入到一個臨時文件(此時內存中的數據是原來的兩倍哦),最后再將臨時文件替換之前的備份文件。
-
所以Redis 的持久化和數據的恢復要選擇在夜深人靜的時候執行是比較合理的。
注意事項
- SHUTDOWN 和 FLUSHALL 命令都會觸發RDB快照,這是一個坑,請大家注意
AOF 詳解
AOF :Redis 默認不開啟。它的出現是為了彌補RDB的不足(數據的不一致性),所以它采用日志的形式來記錄每個寫操作,并追加到文件中。Redis 重啟的會根據日志文件的內容將寫指令從前到后執行一次以完成數據的恢復工作
從配置文件了解AOF
- 打開 redis.conf 文件,找到 APPEND ONLY MODE 對應內容
- redis 默認關閉,開啟需要手動把no改為yes:appendonly yes
- 指定本地數據庫文件名,默認值為 appendonly.aof:appendfilename "appendonly.aof"
- 指定更新日志條件
# appendfsync always appendfsync everysec # appendfsync no /* always:同步持久化,每次發生數據變化會立刻寫入到磁盤中。性能較差當數據完整性比較好(慢,安全) everysec:出廠默認推薦,每秒異步記錄一次(默認值) no:不同步 */
配置重寫觸發機制
auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb /*當AOF文件大小是上次rewrite后大小的一倍且文件大于64M時觸發。一般都設置為3G,64M太小了*/
?
觸發AOF快照
- 根據配置文件觸發,可以是每次執行觸發,可以是每秒觸發,可以不同步
根據AOF文件恢復數據
- 正常情況下,將appendonly.aof 文件拷貝到redis的安裝目錄的bin目錄下,重啟redis服務即可。但在實際開發中,可能因為某些原因導致appendonly.aof 文件格式異常,從而導致數據還原失敗,可以通過命令redis-check-aof --fix appendonly.aof 進行修復 。從下面的操作演示中體會
- 此處的bin文件夾,是我們人為創建的,其中就是我們通過make install之后,在src文件夾里面生成的可執行的文件
AOF的重寫機制
- 前面也說到了,AOF的工作原理是將寫操作追加到文件中,文件的冗余內容會越來越多。所以 Redis 新增了重寫機制。當AOF文件的大小超過所設定的閾值時,Redis就會對AOF文件的內容進行壓縮
- 重寫的原理:Redis 會fork出一條新進程,讀取內存中的數據,并重新寫到一個臨時文件中,并沒有讀取舊文件。最后替換舊的aof文件。
- 觸發機制:當AOF文件大小是上次rewrite后大小的一倍且文件大于64M時觸發。這里的“一倍”和“64M” 可以通過配置文件修改
AOF 的優缺點
優點:
-
數據的完整性和一致性更高
缺點:
-
因為AOF記錄的內容多,文件會越來越大,數據恢復也會越來越慢
總結
- Redis 默認開啟RDB持久化方式,在指定的時間間隔內,執行指定次數的寫操作,則將內存中的數據寫入到磁盤中。
- RDB 持久化適合大規模的數據恢復但它的數據一致性和完整性較差。
- Redis 需要手動開啟AOF持久化方式,默認是每秒將寫操作日志追加到AOF文件中。
- AOF 的數據完整性比RDB高,但記錄內容多了,會影響數據恢復的效率。
- Redis 針對 AOF文件大的問題,提供重寫的瘦身機制。
- 若只打算用Redis 做緩存,可以關閉持久化。
- 若打算使用Redis 的持久化。建議RDB和AOF都開啟。其實RDB更適合做數據的備份。AOF出問題了,還有RDB