目錄
- 概述
- RDB
- AOF
- 如何選擇持久化機制
1、概述
Redis 是記憶體資料庫，如果不能將記憶體中的資料保存到磁盤中，那么一旦服務器行程退出，服務器的資料庫資料也會消失，所以Redis提供了持久化的功能,redis分為兩種持久化方式：RDB和AOF，有以下幾個特點：
-
1.RDB持久化方式能夠在指定的時間間隔能對你的資料進行快照存盤，
-
2.AOF持久化方式記錄每次對服務器寫的操作，當服務器重啟的時候會重新執行這些命令來恢復原始的資料，AOF命令以redis協議追加保存每次寫的操作到檔案末尾，Redis還能對AOF檔案后臺重寫，使得AOF檔案的體積不至于過大，
-
3.如果你只希望你的資料在服務器運行的時候存在，你也可以不使用任何持久化的方式，
-
4.你也可以同時開啟兩種持久化方式，在這種情況下，當redis重啟的時候會優先載入AOF檔案來恢復原始的資料，因為在通常情況下AOF檔案保存的資料集要比RDB檔案保存的資料集要完整，
2、RDB
1、概念
在指定的時間間隔內將記憶體中的資料集快照寫入磁盤中，它恢復的時候是將快照中的檔案直接讀取到記憶體中，
2、持久化機制-BGSAVE
通常，會立即回傳ok,Redis行程會執行fork操作創建子行程，Redis在fork時，父行程會繼續為客戶端提供服務，子行程會將資料持久化到硬碟上，然后退出，如果已經在后臺執行保存或者正在運行另一個非后臺保存的行程，特別是正在進行AOF寫入時，則會回傳錯誤，如果使用了bgsave任務，而正在進行AOF寫入時，該命令將立即回傳ok,并計劃在下一次機會運行后臺保存，阻塞只會在fork階段，
客戶端可以使用lastsave命令檢查操作是否成功，
3、持久化機制-SAVE
不會接受客戶端執行的操作命令，等持久化作業完成之后，會將新的檔案替換舊的檔案，
4、持久化機制-自動觸發
在redis.conf中可以配置，讓用戶自定義save屬性，讓服務器每一段時間內執行一次bgsave操作，
# 服務器在900秒內，對資料庫進行了至少1次修改
save 900 1
# 服務器在300秒內，對資料庫進行了至少10次修改
save 300 10
# 服務器在60秒內，對資料庫進行了至少10000次修改
save 60 10000
# bgsave發生錯誤時是否停止寫入，一般為yes
stop-writes-on-bgsave-error yes
# 持久化時是否使用LZF壓縮字串物件?
rdbcompression yes
# 是否對rdb檔案進行校驗和檢驗，通常為yes
rdbchecksum yes
# RDB持久化檔案名
dbfilename dump.rdb
# 持久化檔案存盤目錄
dir ./
5、恢復資料機制
只需要將rdb檔案放在我們redis啟動目錄就可以了，redis啟動的時候會自動檢查檔案并恢復其中的資料，
6、優點
- RDB是一個非常緊湊的檔案，它保存了某個時間點得資料集，非常適用于資料集的備份，比如你可以在每個小時報保存一下過去24小時內的資料，同時每天保存過去30天的資料，這樣即使出了問題你也可以根據需求恢復到不同版本的資料集，
- RDB是一個緊湊的單一檔案，很方便傳送到另一個遠端資料中心或者亞馬遜的S3（可能加密），非常適用于災難恢復，
- RDB在保存RDB檔案時父行程唯一需要做的就是fork出一個子行程，接下來的作業全部由子行程來做，父行程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能，
- 與AOF相比，在恢復大的資料集的時候，RDB方式會更快一些，
7、缺點
-
如果你希望在redis意外停止作業（例如電源中斷）的情況下丟失的資料最少的話，那么RDB不適合你，雖然你可以配置不同的save時間點(例如每隔5分鐘并且對資料集有100個寫的操作)，是Redis要完整的保存整個資料集是一個比較繁重的作業，你通常會每隔5分鐘或者更久做一次完整的保存，萬一在Redis意外宕機，你可能會丟失幾分鐘的資料，
-
RDB 需要經常fork子行程來保存資料集到硬碟上，當資料集比較大的時候，fork的程序是非常耗時的，可能會導致Redis在一些毫秒級內不能回應客戶端的請求，如果資料集巨大并且CPU性能不是很好的情況下，這種情況會持續1秒，AOF也需要fork，但是你可以調節重寫日志檔案的頻率來提高資料集的耐久度，
3、AOF
1、概念
以日志的形式來記錄每個寫操作，將Redis執行過的所有指令記錄下來（讀操作不記錄），只許追加檔案但不可以改寫檔案，Redis啟動之扯訓讀取該檔案重新構建資料，換言之，Redis重啟的話就會根據日志檔案的內容將寫的指令從前到后執行一次以完成資料的恢復作業，
2、持久化原理
所有操作的命令會追加在檔案中，
3、開啟AOF持久化
# 開啟aof持久化方式，默認no
appendonly no
# aof 持久化生成的檔案名稱
appendfilename "appendonly.aof"
# 三種持久化機制
# appendfsync always
appendfsync everysec
# appendfsync no
4、三種觸發持久化機制
-
always
同步持久化，每次發生資料變更會被立即持久化到硬碟中，性能比較差，但是資料完整性好， -
everysec
異步操作，每秒持久化資料到硬碟一次，可能會丟失一秒的資料， -
no
從不持久化到硬碟，
5、AOF檔案損壞
如果 aof 檔案被破壞，redis服務是啟動不了的，redis本身提供了修復了工具，redis-check-aof --fix appendonly.aof
5、優點
- 根據配置不同的策略，讓你選擇持久化的方式，
- AOF檔案是一個只進行追加的日志檔案，所以不需要寫入seek，即使由于某些原因(磁盤空間已滿，寫的程序中宕機等等)未執行完整的寫入命令，你也也可使用redis-check-aof工具修復這些問題，
- Redis 可以在 AOF 檔案體積變得過大時，自動地在后臺對 AOF 進行重寫： 重寫后的新 AOF 檔案包含了恢復當前資料集所需的最小命令集合， 整個重寫操作是絕對安全的，因為 Redis 在創建新 AOF 檔案的程序中，會繼續將命令追加到現有的 AOF 檔案里面，即使重寫程序中發生停機，現有的 AOF 檔案也不會丟失， 而一旦新 AOF 檔案創建完畢，Redis 就會從舊 AOF 檔案切換到新 AOF 檔案，并開始對新 AOF 檔案進行追加操作，
- AOF 檔案有序地保存了對資料庫執行的所有寫入操作，這些寫入操作以 Redis 協議的格式保存， 因此 AOF 檔案的內容非常容易被人讀懂，對檔案進行分析（parse）也很輕松，匯出（export）AOF檔案也非常簡單：舉個例子， 如果你不小心執行了 FLUSHALL 命令， 但只要 AOF 檔案未被重寫，那么只要停止服務器，移除 AOF 檔案末尾的 FLUSHALL 命令，并重啟 Redis，就可以將資料集恢復到 FLUSHALL 執行之前的狀態，
6、缺點
- 對于相同的資料集來說，AOF 檔案的體積通常要大于 RDB 檔案的體積，
- 根據所使用的 fsync 策略，AOF 的速度可能會慢于 RDB ， 在一般情況下， 每秒 fsync 的性能依然非常高， 而關閉 fsync 可以讓 AOF 的速度和 RDB 一樣快， 即使在高負荷之下也是如此， 不過在處理巨大的寫入載入時，RDB 可以提供更有保證的最大延遲時間（latency），
4、如何選擇持久化機制
開啟兩種持久化方式，根據自己的業務需求針對redis進行配置的調整，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/257044.html
標籤：NoSQL