Redis--Redis的持久化

參考博客傳送門：

http://doc.redisfans.com/topic/persistence.html
https://www.cnblogs.com/chenpingzhao/p/5158791.html

什麼是Redis的持久化？

Redis的持久化就是把內存的數據寫到磁盤中去，防止服務宕機了內存數據丟失。
當然了，你可以關閉持久化，讓數據只在服務器運行時存在。

Redis持久化有幾種，分別是什麼，各自有什麼優缺點

Redis 提供了兩種持久化方式:快照（RDB文件 默認）和追加式文件（AOF文件）

RDB是Redis DataBase縮寫，是指在指定的時間間隔能對你的數據進行快照存儲。
它所生成的 RDB 文件是一個壓縮的二進制文件，通過該文件可以還原生成 RDB 文件時的數據庫狀態
PS：數據庫狀態是指 Redis 服務器的非空數據庫以及他們鍵值對的統稱

RDB 文件的創建

有兩個命令可以生成 RDB 文件，一個是 SAVE、另一個是 BGSAVE。

兩者的區別在於：前者會阻塞 Redis 服務器進程，直到 RDB 文件創建完畢爲止。

而在服務器進程阻塞期間，服務器是不能處理任何命令請求的。

後者則不會阻塞服務器進程，因爲是通過 fork 一個子進程，並讓其去創建 RDB 文件，而服務器進程（父進程）繼續則繼續處理命令請求。

當寫完數據庫狀態後，新 RDB 文件就會原子地替換舊的 RDB 文件。

RDB 文件的載入

RDB 文件的載入是在服務器啓動時自動執行的，所以沒有用於載入的命令，期間阻塞主進程。

只要沒有開啓 AOF 持久化功能，在啓動時檢測到有 RDB 文件，就會自動載入。

當服務器有開啓 AOF 持久化功能時，服務器將會優先使用 AOF 文件來還原數據庫狀態。原因是 AOF 文件的更新頻率通常比 RDB 文件的更新頻率高。

Redis載入RDB文件時，會對RDB文件進行校驗，如果文件損壞，則日誌中會打印錯誤，Redis啓動失敗。

RDB的優點有:

1. RDB 保存了 Redis 在某個時間點上的數據集，非常適合用於進行備份：

2. RDB 非常適用於災難恢復：它只有一個文件，並且內容都非常緊湊，可以（在加密後）將它傳送到其他地方。

3. RDB 可以最大化 Redis 的性能：父進程在保存 RDB 文件時唯一要做的就是 fork 出一個子進程，然後這個子進程就會處理接下來的所有保存工作，父進程無須執行任何磁盤 I/O 操作。

4. RDB 在恢復大數據集時的速度比 AOF 的恢復速度要快。

RDB的缺點有：

1. 如果需要儘量避免在服務器故障時丟失數據，那麼不適合用RDB 。 雖然 Redis 允許你設置不同的保存點來控制保存 RDB 文件的頻率， 但是， 因爲RDB 文件需要保存整個數據集的狀態， 所以它並不是一個輕鬆的操作。 因此你可能會至少 5 分鐘才保存一次 RDB 文件。 在這種情況下， 一旦發生故障停機， 你就可能會丟失好幾分鐘的數據。

2. 每次保存 RDB 的時候，Redis 都要 fork() 出一個子進程，並由子進程來進行實際的持久化工作。 在數據集比較龐大時， fork() 可能會非常耗時，造成服務器在某某毫秒內停止處理客戶端； 如果數據集非常巨大，並且 CPU 時間非常緊張的話，那麼這種停止時間甚至可能會長達整整一秒。 雖然 AOF 重寫也需要進行 fork() ，但無論 AOF 重寫的執行間隔有多長，數據的耐久性都不會有任何損失。

AOF是Append-only file縮寫，是指記錄每次對服務器寫的操作,當服務器重啓的時候會重新執行這些命令來恢復原始的數據。 AOF 文件中的命令全部以 Redis 協議的格式來保存，新命令會被追加到文件的末尾。

AOF 持久化實現

AOF 持久化功能的實現可以分爲 3 個步驟：命令追加（到 AOF 緩衝區）、文件寫入（緩衝區內容寫到 AOF 文件）、文件同步（AOF 文件保存磁盤）
Redis 服務器進程就是一個事件循環，這個循環中的文件事件（socket 的可讀可寫事件）負責接收客戶端的命令請求，以及向客戶端發送命令結果。

因爲服務器在處理文件事件時，可能會發生寫操作，使得一些內容會被追加到 AOF 緩衝區末尾。所以，在服務器每次結束一個事件循環之前 ，都會調用 flushAppendOnlyFile 方法。

這個方法執行以下兩個工作：

WRITE：根據條件，將緩衝區內容寫入到 AOF 文件。

SAVE：根據條件，調用 fsync 或 fdatasync 函數，將 AOF 文件保存到磁盤中。

兩個步驟都需要根據一定的條件來執行，而這些條件由 Redis 配置文件中的 appendfsync 選項來決定的，一共有三個選擇：

appendfsync always：每次執行完一個命令之後， WRITE 和 SAVE 都會被執行

appendfsync everysec：SAVE 原則上每隔一秒鐘就會執行一次。

appendfsync no：每次執行完一個命令之後， WRITE 會執行，SAVE 都會被忽略
（只會在以下任意一種情況中被執行：
Redis 被關閉
AOF 功能被關閉
系統的寫緩存被刷新（可能是緩存已經被寫滿，或者定期保存操作被執行。完成依賴 OS 的寫入，一般爲 30 秒 左右一次））

AOF 重寫

既然 AOF 持久化是通過保存寫命令到文件的，那隨着時間的推移，這個 AOF 文件記錄的內容就越來越多，文件體積也就越來越大，對其進行數據還原的時間也就越來越久，這時候就需要用到AOF的重寫功能了。

通過該功能來創建一個新的 AOF 文件來代替舊文件。並且兩個文件所保存的數據庫狀態一樣，但新文件不會包含任何冗餘命令，所以新文件要比舊文件小得多。

這個重寫功能是通過讀取服務器當前的數據庫狀態來實現的。雖然叫做“重寫”，但實際上並沒有對舊文件進行任何讀取修改。

AOF的特點有：

1. AOF 文件有序地保存了對數據庫執行的所有寫入操作， 這些寫入操作以 Redis 協議的格式保存， 因此 AOF 文件的內容非常容易被人讀懂， 對文件進行分析（parse）也很輕鬆。 導出（export） AOF 文件也非常簡單： 舉個例子， 如果你不小心執行了 FLUSHALL 命令， 但只要 AOF 文件未被重寫， 那麼只要停止服務器， 移除 AOF 文件末尾的 FLUSHALL 命令， 並重啓 Redis ， 就可以將數據集恢復到 FLUSHALL 執行之前的狀態。

2. 使用 AOF 持久化會讓 Redis 變得非常耐久：你可以設置不同的 fsync 策略，比如無 fsync ，每秒鐘一次 fsync ，或者每次執行寫入命令時 fsync 。 AOF 的默認策略爲每秒鐘 fsync 一次，在這種配置下，Redis 仍然可以保持良好的性能，並且就算髮生故障停機，也最多隻會丟失一秒鐘的數據（ fsync 會在後臺線程執行，所以主線程可以繼續努力地處理命令請求）。

3. AOF 文件是一個只進行追加操作的日誌文件，因此對 AOF 文件的寫入不需要進行 seek ， 即使日誌因爲某些原因而包含了未寫入完整的命令（比如寫入時磁盤已滿，寫入中途停機，等等）， redis-check-aof 工具也可以輕易地修復這種問題。

4. Redis 可以在 AOF 文件體積變得過大時，自動地在後臺對 AOF 進行重寫： 重寫後的新 AOF 文件包含了恢復當前數據集所需的最小命令集合。 整個重寫操作是絕對安全的，因爲 Redis 在創建新 AOF 文件的過程中，會繼續將命令追加到現有的 AOF 文件裏面，即使重寫過程中發生停機，現有的 AOF 文件也不會丟失。 而一旦新 AOF 文件創建完畢，Redis 就會從舊 AOF 文件切換到新 AOF 文件，並開始對新 AOF 文件進行追加操作。

AOF的缺點有：

1. 對於相同的數據集來說，AOF 文件的體積通常要大於 RDB 文件的體積。

2. 根據所使用的 fsync 策略，AOF 的速度可能會慢於 RDB 。 在一般情況下， 每秒 fsync 的性能依然非常高， 而關閉 fsync 可以讓 AOF 的速度和 RDB 一樣快， 即使在高負荷之下也是如此。 不過在處理巨大的寫入載入時，RDB 可以提供更有保證的最大延遲時間（latency）。

Redis 還可以同時使用 AOF 持久化和 RDB 持久化。 在這種情況下， 當 Redis 重啓時， 它會優先使用 AOF 文件來還原數據集， 因爲 AOF 文件保存的數據集通常比 RDB 文件所保存的數據集更完整，更新頻率更高。

持久化的配置

RDB配置：

時間策略（默認）
save 900 1      // 900 秒內，對數據庫至少修改 1 次。下面同理    
save 300 10     
save 60 10000       

文件名稱
dbfilename dump.rdb

文件保存路徑
dir ./

如果持久化出錯，主進程是否停止寫入(默認情況下，如果Redis在後臺生成快照的時候失敗，那麼就會停止接收數據，目的是讓用戶能知道數據沒有持久化成功。但是如果你有其他的方式可以監控到Redis及其持久化的狀態，那麼可以把這個功能禁止掉。)
stop-writes-on-bgsave-error yes

是否壓縮(默認Redis會採用LZF對數據進行壓縮。如果你想節省點CPU的性能，你可以把壓縮功能禁用掉，但是數據集就會比沒壓縮的時候要打。)
rdbcompression yes

導入時是否檢查(從版本5的RDB的開始，一個CRC64的校驗碼會放在文件的末尾。這樣更能保證文件的完整性，但是在保存或者加    載文件時會損失一定的性能（大概10%）。如果想追求更高的性能，可以把它禁用掉，這樣文件在寫入校驗碼時會用0替代，加載的時  候看到0就會直接跳過校驗)
rdbchecksum yes

如果想禁用快照保存的功能，可以通過註釋掉所有"save"配置達到，或者在最後一條"save"配置後添加如下的配置：
save ""

AOF配置：

啓用AOF配置
appendonly yes

文件名稱
appendfilename "appendonly.aof"

可靠性：
appendfsync always：每當有新命令追加到AOF的時候調用fsync。速度最慢，但是最安全。
appendfsync everysec：每當有新命令追加到AOF的時候調用fsync。速度最慢，但是最安全。
appendfsync no：從不fsync，交由系統去處理。這個方式速度最快，但是安全性沒有保證