淺談 Redis 持久化

前言

前面咱們講了 Redis 的數據結構（Redis那些事之數據結構），今天咱們來看看 Redis 的持久化，Redis 的持久化分兩種 RDB 和 AOF。這兩種各有優缺點，咱們先看下官方是怎麼描述這兩種結構的:

RDB持久性以指定的時間間隔執行數據集的時間點快照。
AOF持久性記錄服務器接收的每一個寫入操做，將在服務器啓動時再次播放，重建原始數據集。 使用與Redis協議自己相同的格式以僅追加方式記錄命令。 當Redis太大時，Redis可以重寫日誌背景。

咱們能夠選擇關閉持久化，把 Redis 做爲一個內存緩存使用，也能夠開啓持久化作數據庫使用，RDB 和 AOF 能夠同時開啓，同時開啓的狀況下 Redis 優先讀取 AOF 裏面的數據。最重要的是理解 RDB 和 AOF 的區別和各自的優缺點，以便咱們在不一樣的業務員場景下擇優選擇。

RDB

RDB 持久化能夠手動執行，也能夠根據配置選項按期執行，該功能能夠將某個時間點的數據庫狀態保存到一個 RDB 文件中。由於 RDB 是保存在硬盤中，因此即便 Redis 服務器進程掛掉，只要 RDB 文件存在，Redis 就能夠用它來還原數據狀態。
Redis 提供兩個手動執行命令 SAVE、BGSVE，SAVE命令執行時，客戶端發送的因此命令請求都會被阻塞。BGSAVE 命令是由主進程 fork 出一個子進程進行持久化。因此在持久化的過程當中 Redis 還能夠繼續執行客戶端的命令，持久化由子進程執行。由於 BGSAVE 命令是非阻塞的，因此自動執行所有采用的是 BGSAVE 命令。
RDB 文件保存了用戶的寫入和刪除命令，並根據不一樣的數據類型進行相應的編碼，一個標準的 RDB 文件通常有一下部分組成:

1. REDIS
2. db_version RDB 文件版本號
3. database 數據庫
4. EOF 結束標識符
5. check_sum 校驗和

其中 database 的格式爲:

1. SELECTDB 相似 flag 標識，當程序讀到這兒的時候標識接下來讀入的是一個數據庫號碼
2. db_number 數據庫號
3. key_value_pairs 保存了數據庫中因此的鍵值對數據、過時條件等

其中 key_value_pairs 部分的 key 是採用的 SDS 編碼， value 是根據不一樣的數據類型進行存儲（參考：Redis那些事之數據結構）

AOF

除了 RDB 持久化功能以外 Redis 還提供了 AOF（append only file）持久化功能，AOF 是經過保存 Redis服務器所執行的寫命令來記錄數據庫狀態的。
AOF 的實現能夠功能大致分爲 命令追加（append）、文件寫入、文件同步（sync）。
當 AOF 功能打開的時候，服務器在執行完一個寫命令後，會以寫一個是將被執行命令追加到服務器狀態的 aof_buf 緩衝區的末尾。Redis 服務器在一個事件循環（loop）週期裏它會調用一次 flushAppendOnlyFile 函數。考慮是否將 aof_buf 緩衝區中的內容寫入和保存到 AOF 文件裏面。
由於 AOF 是經過客戶端發送的寫命令來保證數據庫的狀態的，因此隨着時間的流失， AOF 文件中的內容可能會出現愈來愈多對一樣一個鍵的修改。文件的體積也愈來愈大，如不加以控制，可能會對 Redis 服務器形成影響，使用 AOF 恢復所需的時間也會加大。 Redis 爲此提供了 AOF 重寫功能， AOF 的重寫並非對現有文件進行分析而後進行重寫，而是遍歷讀取數據庫裏的數據，而後把對應的命令轉成寫入命令，寫入到一個新的文件。這個執行過程一樣是阻塞進行的，因此能夠繼續採用子進程來執行，等子進程處理完後對父進程發送一個信號通知從新執行完畢。而後父進程對原來的 AOF 文件原子性的覆蓋。（在子進程執行重寫的過程，父進程一樣會接收命令，這個期間主進程所接收到的命令都會保存到緩衝區，在執行覆蓋前，Redis服務會把緩衝區的命令追加到子進程發來的 AOF 文件裏面）。

RDB 和 AOF 的優缺點

RDB 的優勢

• RDB 文件很是適合備份，好比能夠根據時間或者是修改的次數，進行歸檔，而後在發生災難的時候輕鬆的根據恢復不一樣的版本數據。
• RDB 很是適合災難恢復，能夠將單個壓縮文件傳輸到遠端數據中心，也能夠傳輸到 Amazon S3（多是加密的）。
• RDB 最大限度地提升了 Redis 的性能，由於 Redis 父進程爲了持久化須要作的惟一工做就是分配一個將完成全部其他工做的孩子。 父實例永遠不會執行磁盤 I/O 或相似操做。
• 與 AOF 相比，RDB 容許使用大數據集更快地重啓。

AOF 的優勢

• 使用 AOF Redis 更持久：你可使用不一樣的 fsync 策略：根本沒有 fsync，每秒 fsync，每次查詢都有 fsync。使用 fsync 的默認策略，每秒寫入性能仍然很好（使用後臺線程執行 fsync，而且當沒有 fsync 正在進行時，主線程將努力執行寫入。）可是你只能丟失一秒的寫入。
• AOF 日誌是僅附加日誌，所以若是停電，則沒有搜索，也沒有損壞問題。即便因爲某種緣由（磁盤已滿或其餘緣由）日誌以半寫命令結束，redis-check-aof 工具也可以輕鬆修復它。
• 當 Redis 太大時，Redis 可以在後臺自動重寫 AOF。重寫是徹底安全的，由於當 Redis 繼續附加到舊文件時，使用建立當前數據集所需的最小操做集生成一個全新的文件，而且一旦第二個文件準備就緒，Redis 會切換兩個並開始附加到新的那一個。
• AOF 以易於理解和解析的格式一個接一個地包含全部操做的日誌。你甚至能夠輕鬆導出 AOF 文件。例如，即便你使用 FLUSHALL 命令刷新了全部錯誤，若是在此期間未執行重寫日誌，你仍然能夠保存數據集，只需中止服務器，刪除最新命令，而後從新啓動 Redis。

RDB 的缺點

• 若是你須要在 Redis 掛掉後將數據的丟失性降到最小，那麼 RDB 可能不合適。你能夠根據配置文件設置不一樣的時間保存點，例如；對數據集進行至少 5 分鐘和100次寫入以後保存 RDB 文件，那麼 5 分鐘內或者修改次數不知足 100 次的數據可能就會丟失。
• RDB 爲了持久化會常常 fork 才能將子進程的數據持久儲存在磁盤上，若是數據集很大， fork 可能會很是耗時，而且若是數據集很是大且 CPU 性能不佳，可能會致使 Redis 中止服務客戶端幾毫秒甚至一秒鐘。 AOF 也須要 fork ，但你能夠調整你想要重寫日誌的頻率而不須要對持久性進行任何權衡。

AOF 的缺點

• 由於 AOF 是保存的寫入命令，因此一樣數據下 AOF 通常比 RDB 文件更大。
• 根據確切的 fsync 策略，AOF 可能比 RDB 慢。通常來講，fsync 設置爲每秒性能仍然很是高，而且在 fsync 禁用的狀況下，即便在高負載下也應該與 RDB 同樣快。即便在寫入負載很大的狀況下，RDB 仍可以提供有關最大延遲的更多保證。