redis持久化：RDB和AOF 及性能建議小結
目錄
- redis持久化：RDB和AOF 及性能建議小結
- 總體介紹
- 官網介紹
- RDB（redis database）
- 是什么
- 默認出廠設定與使用
- save配置引數
- 保存的檔案型別
- 如何觸發RDB快照
- 如何恢復
- 優勢與劣勢
- AOF（append only file）
- 是什么
- 默認出廠配置
- 配置的位置 引數及使用
- 保存的檔案型別
- rewrite重寫原理
- 優勢與劣勢
- 總結及性能建議
總體介紹
官網介紹
redis提供了兩種持久化方式的選擇，分別是RDB和AOF，.
RDB使用時間片切割的方式，在指定的時間間隔內將記憶體中的資料集快照（snapshot）寫入到磁盤中；
AOF持久化通過日志的形式記錄每一個寫操作，在服務重啟時根據日志內容寫指令重頭到位執行一遍，完成資料恢復；
如果你希望資料僅存在于服務運行期間（比如只用redis做快取），可以完全選擇不開啟持久化；
RDB和AOF是可以共存的，當redis重啟時，會選擇AOF的方法來恢復資料，鑒于它保證了資料最大的完整性（一致性），
RDB（redis database）
是什么
在指定的時間間隔內將記憶體中的資料集快照snapshot）寫入到磁盤中，
Redis會單獨創建（fork）一個子行程來進行持久化，會先將資料寫入到一個臨時檔案中，待持久化程序結束了，再用這個臨時檔案替換上一層持久化好的檔案，
默認出廠設定與使用
save配置引數
引數：save 時間間隔 操作次數
redis系統默認配置為每15分鐘有1次寫操作or每5分鐘有100次寫操作or一分鐘內有10000次寫操作時，觸發rbd快照，
保存的檔案型別
如何觸發RDB快照
- 符合組態檔中默認的快照配置
- 執行save或bgsave命令
- save：只管保存，其他全部阻塞
- bgsave：在后臺異步進行快照操作，同時可以回應客戶端請求
- 執行flushall命令，也會生成空的dump.rdb檔案，無意義
如何恢復
將備份檔案（dump.rdb）移動到redis安裝目錄，啟動服務即可
優勢與劣勢
- 優勢
- 在對資料的完整性和一致性要求不高的情況下，適合大規模的資料恢復
- 劣勢
- 在一定時間間隔的時間點萬一意外宕機，會丟失最后一次快照的修改
- fork子行程時，記憶體中的資料被克隆了一份，膨脹一倍
AOF（append only file）
是什么
以日志形式記錄每一個寫操作（只許追加不可改寫），在服務重啟時根據日志內容中的寫指令重頭到位執行一次，完成資料恢復
默認出廠配置
配置的位置 引數及使用
- 同步策略
- 每修改同步：appendfsync always 每次修改立即記錄，性能較差但完整性較好
- 每秒同步：appendfsync everysec 異步操作，每秒記錄，若一秒內宕機則有資料丟失
- 不同步：appendfsync no 從不同步
保存的檔案型別
appendonly.aof
rewrite重寫原理
AOF采用檔案追加的方式，為避免出現檔案越寫越大的情況，新增了重寫機制，當AOF檔案大小超出指定閾值時，會啟動AOF的檔案內容壓縮，只保存恢復資料的最小指令集，可以使用命令bgrewriteaof
當AOF檔案大小是上次rewrite后大小的一倍且檔案大于64M時觸發（真實開發中不可能這么小）
優勢與劣勢
- 優勢：資料完整性和一致性好于RDB
- 劣勢：
- 相同大小的資料集而言AOF檔案要遠大于RDB檔案，恢復速度要慢與RDB
- AOF運行效率要慢與RDB
總結及性能建議
- 官網建議同時開啟兩種持久化方式，若只用做快取，資料只在服務器運行的情況下存在，也可以選擇不用任何持久化
- RDB只用做后備用途，只保留每15分鐘備份一次的設定足夠
- AOF的重寫默認值設定為5GB及以上，enabled AOF帶來的代價分別是
- 持續的IO
- rewrite帶來的阻塞（在硬碟許可的情況下，盡量降低rewrite的頻率）
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/267494.html
標籤：其他
上一篇：線性表的基本操作及原始碼