Redis持久化
RDB快照
在默認情況下，Redis將記憶體資料庫快照保存到dump.rdb的二進制檔案中，
可以對Redis進行設定，讓它在“N秒內資料集至少有N個改動”， 這一條件被滿足時，自動保存一次資料集，比如說：讓Redis滿足“60秒內至少有1000個鍵被改動”這一個條件時，自動保存一次資料集，
save 60 1000
除了在組態檔中使用save關鍵字設定RDB快照，還可以在命令列中手動執行命令生成RDB快照，進入redis客戶端執行命令save或bgsave可以生成dump.rdb檔案，
每次執行命令都會將所有redis記憶體快照保存到一個rdb檔案里，并覆寫原有的rdb快照檔案，
save是同步命令，bgsave是異步命令，bgsave會從redis主行程fork出一個子行程專門用來生成rdb二進制檔案，
AOF（append only file）
快照功能并不是非常durable，如果redis因為某些原因而造成故障停機，那么服務器將丟失最近寫入且未保存到快照中的那些資料，從1.1版本，redis增加了一種完全durable的方式：AOF持久化，將修改的每一條指令記錄進appendonly.aof中，修改組態檔來打開aof功能：
appendonly yes
打開aof功能，每當redis執行一個改變資料集的命令時，這個命令就會追加到aof檔案的末尾，這樣的話，當redis重新啟動時，程式就會通過執行aof檔案中的命令來達到重建資料集的目的，
可以配置redis多久才將命令持久化到磁盤一次，
appendfsync always：每次有新命令追加到aof檔案時就執行一個持久化，非常慢但是安全
appendfsync everysec：每秒執行一次持久化，足夠快（和使用rdb持久化差不多）并且在故障時只會丟失1秒鐘的資料
appendfsync no：從不持久化，將資料交給作業系統來處理，redis處理命令速度加快但是不安全，
默認情況下 ，每秒執行一次fsync， 這種fsync策略可以兼顧安全性和速度，
rdb和aof的區別：
redis啟動時如果既有rdb檔案又有aof檔案則優先選擇aof檔案恢復資料，因為aof檔案一般來說資料更安全一點，
二、AOF重寫
aof檔案里可能有太多“瑣碎”指令，所以aof會定期根據記憶體的最新資料重新生成aof檔案
有兩個配置可以控制aof自動重寫的頻率：
auto-aof-rewrite-min-size 64mb： aof檔案至少要達到64m才會觸發制動重寫，檔案太小恢復速度本來就很快，重寫的意義不大
auto-aof-rewrite-percentage 100：aof檔案上一次重寫后檔案大小增長了100%則再次觸發重寫
當然aof還可以手動重寫，進入redis客戶端執行命令bgrewriteaof重寫aof，
觸發aof重寫時，redis會fork一個子行程去做，不會對redis正常命令處理有太多影響，
Redis 4.0混合持久化
重啟redis恢復資料集時，很少會使用rdb來恢復記憶體狀態，因為會丟失大量資料，通常會使用aof日志恢復資料，但是重放aof日志性能相對rdb來說要慢很多，這樣在redis實體很大的情況下，啟動需要花費很長時間，Redis4.0為了解決這個問題，帶來了新的持久化選項——混合持久化，
aof-use-rdb-preamble yes
混合持久化aof檔案結構：
如果開啟了混合持久化，aof在重寫時，不再是單純將記憶體資料轉換為RESP命令寫入aof檔案，而是將重寫這一刻之前的記憶體做rdb快照處理，并且將rdb快照內容和增量的aof修改記憶體資料的命令存在一起，都寫入新的aof檔案，新的aof檔案一開始不叫appendonly.aof，等到重寫完成后，新的aof檔案才會進行改名，原子的覆寫原有的aof檔案，完成新舊兩個aof檔案的替換，
于是在redis重啟的時候，可以先加載rdb檔案，然后再重放增量的aof日志就可以完全替代之前的aof全量檔案重放，因此重啟效率大幅得到提高，
還沒關注我的公眾號？
- 掃文末二維碼關注公眾號【小強的進階之路】可領取如下:
- 學習資料： 1T視頻教程：涵蓋Javaweb前后端教學視頻、機器學習/人工智能教學視頻、Linux系統教程視頻、雅思考試視頻教程；
- 100多本書：包含C/C++、Java、Python三門編程語言的經典必看圖書、LeetCode題解大全；
- 軟體工具：幾乎包括你在編程道路上的可能會用到的大部分軟體；
- 專案原始碼：20個JavaWeb專案原始碼，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/234146.html
標籤：其他
上一篇：Redis學習四（運維指南）.