持久化介紹
redis 提供了兩種方式方式進行資料的持久化(將資料儲存到硬碟中);第一種稱為快照(snapshotting)RDB,它將某一時刻的所有資料都寫入硬碟,所以快照是一次全量備份,並且儲存的資料形式是二進位制序列化形式;另一種方式是隻追加檔案(append-only file)AOF, 它會在執行命令時將命令複製一份到硬碟中,AOF在長期執行中會變的非常龐大,資料庫重啟載入AOF日誌將會很慢;
redis 將資料持久化的主要原因就是重用資料,或者防止系統故障,備份資料;
兩種方式的持久化是可以同時存在的,但是當Redis重啟時,AOF檔案會被優先用於重建資料
工作原理
快照工作原理
redis的快照必須要求檔案IO操作,單執行緒的redis進行多餘的IO操作會影響伺服器的效能,所以redis採用COW(copy on write)機制實現快照的持久化;
- 首先redis進行會fork一個子程式,此時就存在父子程式;
- 父程式負責進行修改操作,記憶體持續增加;而子程式資料不做任何變化;
- 子程式將瞬間資料寫入磁碟的rdb檔案
AOF工作原理
AOF日誌存放了redis指令順序序列;所以只要重新執行AOF檔案包含所有的命令就可以實現AOF檔案記錄的所有資料;
常用配置
RDB配置
預設檔案
dbfilename dump.rdb
dir ./
redis會將資料預設dump至dump.rdb檔案中;我們可以通過配置修改dump的頻率;
#在900秒(15分鐘)之後,如果至少有1個key發生變化,則dump記憶體快照。
save 900 1
#在300秒(5分鐘)之後,如果至少有10個key發生變化,則dump記憶體快照。
save 300 10
#在60秒(1分鐘)之後,如果至少有10000個key發生變化,則dump記憶體快照
save 60 10000
如果想要禁用快照功能,註釋掉如上配置,開啟save ""
配置
save ""
#save 900 1
#save 300 10
#save 60 10000
手動備份
save命令是阻塞命令 ,當伺服器接收到save命令之後就會開始拍攝快照,在此期間不會處理其他請求;
bgsave命令也是立即拍攝快照,非阻塞命令,而是fork一個子執行緒進行備份快照;
缺點
- 每隔一段時間進行一次持久化,如果redis崩潰,可能會導致部分資料丟失問題;
- RDB使用
fork()
子程式進行資料的持久化,如果資料量大,可能花費的時間較長,redis會造成明顯的卡頓幾秒現象; - 很好的備份效果,容易進行資料恢復;
優點
- 相比AOF,在資料量比較大的情況下,RDB的啟動速度更快;
- RDB使用
fork()
子程式進行資料的持久化,本身不會有多餘的IO操作;
AOF配置
啟用AOF
appendonly yes
預設檔案
appendfilename "appendonly.aof"
dir ./
fsync
如果redis發生當機事件,有可能沒來的及資料寫入磁碟;此時redis AOF 的 fsync 策略能夠保證redis保持高效能,和儘可能的減少資料丟失;預設就是使用 1s執行一次同步;
#每次有資料修改發生時都會寫入AOF檔案。
#appendfsync always
#每秒鐘同步一次,該策略為AOF的預設策略。
appendfsync everysec
#從不同步。高效但是資料不會被持久化。
#appendfsync no
AOF重寫
AOF日誌檔案會隨著redis執行越來越龐大,Redis 提供了 bgrewriteaof 指令用於對 AOF 日誌進行瘦身;也可以使用配置檔案進行自動瘦身;
# 當前AOF檔案大小是上次日誌重寫得到AOF檔案大小的二倍時,自動啟動新的日誌重寫過程。
auto-aof-rewrite-percentage 100
# 當前AOF檔案啟動新的日誌重寫過程的最小值,避免剛剛啟動Reids時由於檔案尺寸較小導致頻繁的重寫。
auto-aof-rewrite-min-size 64mb
要禁用自動的日誌重寫功能,我們可以把百分比設定為0
auto-aof-rewrite-percentage 0
優點
- 使用fsync每秒一次同步,資料完整性較高;
- redis如果發生當機,支援使用redis-check-aof 工具修復損壞的AOF檔案
缺點
- AOF檔案的大小一般會比RDB檔案大
- AOF在執行效率上往往會慢於RDB
關注公眾號:知識追尋者,獲取一線大廠面經