Redis——Redis用作資料庫（持久化/RDB/AOF）

執拗如少年發表於2020-10-03
Redis資料庫持久化

Redis 用作資料庫

文章目錄

Redis 用作快取，其特點之一就是資料可以丟，只需要保證其響應急速，效能較高！

但是如果把 Redis 做資料庫：資料絕對不能丟的，所以除了保證其速度之外，還必須保證其永續性，資料一定不可以丟失

而我們知道 Redis 處於記憶體，記憶體資料掉電易失！所以如果想要使用 Redis 作為資料庫，必須要保證其永續性

只要是儲存層，為了保證資料安全，都會有如下兩個通用的功能：

  • 快照/副本：記錄某一時刻資料庫中所有的正確資料狀況。可以儲存在本地主機，也可以拷貝到另一臺遠端主機，一旦出現斷電，甚至伺服器癱瘓，也可以根據快照恢復某一時刻的正常資料
  • 日誌：使用者發生增刪改的時候，所有的操作都會記錄到一個日誌檔案。如果週一資料正常，週二系統上線新功能出現一個致命錯誤，造成大量資金損失，此時可以將系統緊急停服，根據日誌將資料回滾到一個正常狀態

官網持久化介紹：http://redis.cn/topics/persistence.html

Redis 提供了不同級別的持久化方式:

  • RDB持久化方式能夠在指定的時間間隔能對你的資料進行快照儲存.
  • AOF持久化方式記錄每次對伺服器寫的操作,當伺服器重啟的時候會重新執行這些命令來恢復原始的資料,AOF命令以redis協議追加儲存每次寫的操作到檔案末尾。Redis還能對AOF檔案進行後臺重寫,使得AOF檔案的體積不至於過大.
  • 如果你只希望你的資料在伺服器執行的時候存在,你也可以不使用任何持久化方式.
  • 你也可以同時開啟兩種持久化方式, 在這種情況下, 當redis重啟的時候會優先載入AOF檔案來恢復原始的資料,因為在通常情況下AOF檔案儲存的資料集要比RDB檔案儲存的資料集要完整.

最重要的事情是瞭解RDB和AOF持久化方式的不同，這也是面試高頻，下面我們就來詳細學習以下 RDB 和 AOF

一、持久化之RDB

RDB 全稱 redis database，在指定的時間間隔內將記憶體中的資料集快照寫入磁碟，也就是行話講的 Snapshot 快照，它恢復時直接將快照檔案直接讀到記憶體裡；

Redis會單獨建立（fork）一個子程式來進行持久化，會先將資料寫入到一個臨時檔案中，主程式是不進行任何 IO操作的，它就確保了極高的效能；RDB 檔案是在硬碟上的二進位制檔案，是 Redis 在記憶體儲存的資料在某一時刻的快照

1、時點性

系統中不可能每分每秒都進行快照儲存，這樣會大量佔用系統資源且毫無意義，所以運維人員一般會定時儲存快照

假設使用 RDB 每一小時進行一次快照儲存，假設一個正常系統的快照檔案大小有 10 G，肯定不可能瞬時就能儲存到磁碟，那麼快照儲存該如何實現呢？我們最先想到的一種方式如下圖：

在這裡插入圖片描述

阻塞儲存快照：Redis 主程式阻塞，不再對外提供服務，只進行快照的持久化。這種方式能保證快照的時點性，但是會導致服務停用，這種情況生產環境不會允許發生。所以我們就想讓 Redis 一邊提供服務，一邊進行快照的持久化，處理過程如下：

在這裡插入圖片描述

非阻塞儲存快照：會導致時點混亂，無法儲存正確的快照資訊，導致資料不一致

那麼 RDB 究竟是如何進行持久化呢？——主程式非阻塞繼續提供服務，同時 fork 出子程式進行持久化，處理流程如下：

在這裡插入圖片描述

fork 子程式儲存快照：Redis 主程式繼續對外提供服務，同時 fork 出子程式進行快照持久化。在持久化期間，客戶端對主程式的修改對於 fork 出的子程式是看不到的，所以能夠保證快照的時點性，不會發生混亂

補充：fork 是怎麼實現的？或者說使用 fork 有什麼優勢？

fork 建立子程式不會發生資料的複製，只是會建立引用指標，這樣建立子程式的時候，速度特別快；

只有發生寫操作時才會觸發複製，即 copy on write （寫時複製）機制，不會發生全量的資料修改

在這裡插入圖片描述

fork() 建立子程式優勢：

  • 建立子程式時只需要建立指標引用，不需要資料複製，建立速度快
  • 並不是全量複製資料，佔用空間小

RDB 流程：

在這裡插入圖片描述

2、RDB配置

上面理論學習完之後，Redis 是怎麼完成以 RDB 程式持久化的呢？

  • 人為觸發：可以通過兩個指令人為觸發
    • save：前臺阻塞，不再提供服務，只進行快照持久化。較少使用，使用場景明確——只有明確什麼時間會關機停服維護的時候才可能用到
    • bgsave：後臺非同步非阻塞，fork 建立子程式完成快照的持久化
  • 配置檔案配置 bgsave 規則：
    • save 60 10000：時間達到 60 秒，或者寫運算元達到 10000 次，兩者滿足其一，就會觸發 RDB
    • save 300 10：時間達到 300 秒，或者寫操作到達 10 次，兩者滿足其一，就會觸發 RDB
    • save 900 1：時間達到 900 秒，或者寫運算元達到 1 次，兩者滿足其一，就會觸發 RDB
    • 根據系統的併發量、高峰時點等等靈活設定

3、優缺點

RDB的優點

  • RDB是一個非常緊湊的檔案,它儲存了某個時間點得資料集,非常適用於資料集的備份,比如你可以在每個小時報儲存一下過去24小時內的資料,同時也可以每天儲存過去30天的資料,這樣即使出了問題你也可以根據需求恢復到不同版本的資料集.
  • RDB是一個緊湊的單一檔案,很方便傳送到另一個遠端資料中心或者亞馬遜的S3（可能加密），非常適用於災難恢復.
  • RDB在儲存RDB檔案時父程式唯一需要做的就是fork出一個子程式,接下來的工作全部由子程式來做，父程式不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的效能.
  • 與AOF相比，在恢復大的資料集的時候，RDB方式會更快一些.

RDB的缺點

  • 資料丟失：如果你希望在redis意外停止工作（例如電源中斷）的情況下丟失的資料最少的話，那麼RDB不適合你.雖然你可以配置不同的save時間點(例如每隔5分鐘並且對資料集有100個寫的操作),是Redis要完整的儲存整個資料集是一個比較繁重的工作,你通常會每隔5分鐘或者更久做一次完整的儲存,萬一在Redis意外當機,你可能會丟失幾分鐘的資料
  • 耗時：RDB 需要經常fork子程式來儲存資料集到硬碟上,當資料集比較大的時候,fork的過程是非常耗時的,可能會導致Redis在一些毫秒級內不能響應客戶端的請求.如果資料集巨大並且CPU效能不是很好的情況下,這種情況會持續1秒,AOF也需要fork,但是你可以調節重寫日誌檔案的頻率來提高資料集的耐久度.

總結：

在這裡插入圖片描述

二、持久化之AOF

AOF 即 Append-only file，使用追加寫操作

如果說 RDB 是類似於快照/副本，那麼 AOF 就是類似於日誌。AOF持久化以日誌的形式記錄伺服器所處理的每一個寫、刪除操作，查詢操作不會記錄。而且是以文字的方式記錄，可以開啟檔案看到詳細的操作記錄

在這裡插入圖片描述

redis中，RDB和AOF可以同時開啟，如果開啟了AOF只會用AOF恢復

因為 AOF 是追加寫，只要伺服器不停，日誌檔案就會無限膨脹。假設 redis 服務執行了10年，AOF檔案可能達到數十G，甚至數十T大小，此時可能導致記憶體溢位，而且根據這麼大的檔案中的指令一條一條的進行資料恢復，耗時將會很長

所以在 Redis 4.0 以後，AOF是一個混合體，將老的資料以 RDB 方式儲存到 AOF 檔案中，將增量的以指令的方式 Append 到AOF。既利用了 RDB 的快速，又保證了AOF日誌的全量

1、AOF配置

既然作為資料庫，那麼每次的寫操作都應該要儲存下來，任何一條增刪改操作都不能丟失。但是寫操作都會觸發IO，頻繁的 IO 將會拖慢 redis 的速度，所以 Redis 中對於寫操作有三種級別：

  • 無 fsync：不進行同步（不安全）
  • 每秒 fsync：每秒進行一次同步（預設方式，既保證資料丟失量少，而且速度不算慢，效能比較均衡）
  • 每次寫的時候 fsync：每次寫操作都進行一次同步（頻率過高，拖慢速度）

2、優缺點

AOF 優點

  • 使用AOF 會讓你的Redis更加耐久: 你可以使用不同的fsync策略：無fsync,每秒fsync,每次寫的時候fsync.使用預設的每秒fsync策略,Redis的效能依然很好(fsync是由後臺執行緒進行處理的,主執行緒會盡力處理客戶端請求),一旦出現故障，你最多丟失1秒的資料.
  • 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 執行之前的狀態。

AOF 缺點

  • 長期執行導致日誌檔案體積過大，有可能出現記憶體溢位，而且恢復起來也很慢
  • 根據所使用的 fsync 策略，AOF 的速度可能會慢於 RDB

關聯文章：

Redis入門–萬字長文詳解epoll

Redis——詳解五種資料結構

Redis——Redis的進階使用（管道/釋出訂閱/事務/布隆過濾器）

Redis——Redis用作快取（記憶體回收/穿透/擊穿/雪崩）

相關文章