Redis - 2 - 聊聊Redis的RDB和AOF持久化 - 更新完畢

紫邪情發表於2021-12-11
Redis持久化

1、RDB

1.1）、RDB是什麼？

  • RDB，全稱Redis Database
  • RDB是Redis進行持久化的一種方式，當然：Redis預設的持久化方式也是RDB

1.2）、Redis配置RDB

1.2.1）、編寫配置

  • 注：保證自己的linux中安裝了docker和docker-compose，安裝教程連結如下：

  • 另：老衲的方法是採用docker和docker-compose來進行安裝的Redis。官網讓下載壓縮包，然後安裝gcc，使用make編譯，從而安裝的方式，老衲並沒有採用

  • 配製編寫如下：
    截圖


version: '3.1'
services:
  redis:
    image: redis:6.2.6
    restart: always
    container_name: redis
    environment:
      - TZ=Asia/Shanghai
    ports:
      - 6379:6379
    volumes:
      - ./conf/:/usr/local/redis/
      - ./conf/:/data/
    command: ["redis-server","/usr/local/redis/redis.conf"]
  • 然後儲存即可

1.2.2）、編寫RDB配置

  • 注：老衲的Redis是已經啟動過了的，因此：接下來的一步如果看老衲部落格的人當初不是採用的docker和docker-compose安裝的Redis，那麼經過上面的步驟之後，啟動一下Redis就可以了，怎麼啟動這裡不做說明，可以看一下老衲的docker-compose安裝Redis教程，連結如下：

  • 回到正題，編寫RDB配置
    截圖

    • 最後，儲存即可

# 設定redis登入密碼
requirepass 自己要設定的Redis登入密碼

# RDB設定
save 900 1
save 300 100
save 60 5  # 這裡使用5，是為了本部落格中好測試，這些後面不說了，因為：這是基操，說起來煩得很
dbfilename dump.rdb

1.2.3）、重新啟動Redis，進到Redis的docker容器內部

截截圖

  • 測試：觸發RDB，save自己設定的次數次資料即可
    截圖

1.2.4）、回到對映的生成rdb檔案的目錄

截圖

  • 經過如上的操作之後，RDB就配置成功了，但是：老衲想說的其實不是上面這些，接下來才是我想說的

2、Redis的RDB原理

截圖

3、RDB的觸發條件

  • 1、肯定是使用save命令了（ 先刪掉生成的rdb檔案，從而進行測試 ）
    截圖

  • 截圖

  • 截圖

  • 可見：成功觸發了，後續的演示老衲不再做了，直說有哪些觸發條件

  • 這個命令觸發RDB的原理：

    • save命令會阻塞Redis伺服器程式，直到RDB檔案建立完畢為止，在Redis伺服器阻塞期間，伺服器不能處理任何命令請求

  • 2、使用bgsave命令

    • 這個命令也是推薦的一種，建立一個子程式，由子程式來負責建立RDB檔案，父程式(即Redis主程式)則繼續處理請求

    • 注：bgsave命令執行過程中，只有fork子程式時會阻塞伺服器，而對於save命令，整個過程都會阻塞伺服器，因此save已基本被廢棄，線上環境要杜絕save的使用

  • 3、自動觸發

    • 這個就簡單了，所謂的自動觸發就是前面自己在redis.conf檔案中配置哪些save，滿足條件就觸發了嘛

  • 4、使用flushall命令、以及退出Redis也會觸發（ 先登進去，然後開另一個建立刪掉rdb檔案，再退出就發現也生成了 ）

4、RDB的優缺點

  • 缺點：

    • 進行持久化時有一定的時間間隔（ sava配置那裡 ），如果剛好在哪個時間點內在儲存資料，而此時出現當機了，則：會導致要儲存的資料沒有儲存成功（ 不能保證資料的絕對安全 ）

      • 舉個例子：假如900內是有一次key發生改變就儲存資料，但是：在key正在準備改變時，redis當機了呢？這資料不就沒了嗎（ redis的資料一開始是在記憶體中的，還沒持久化到磁碟 ）

    • RDB是開了一個子程式來進行建立rdb檔案，因此：會造成空間的浪費

———————————————————官方話如下：—————————————————————————————

  • 如果你希望在redis意外停止工作（例如電源中斷）的情況下丟失的資料最少的話，那麼RDB不適合你.雖然你可以配置不同的save時間點(例如每隔5分鐘並且對資料集有100個寫的操作),是Redis要完整的儲存整個資料集是一個比較繁重的工作,你通常會每隔5分鐘或者更久做一次完整的儲存,萬一在Redis意外當機,你可能會丟失幾分鐘的資料

  • RDB 需要經常fork子程式來儲存資料集到硬碟上,當資料集比較大的時候,fork的過程是非常耗時的,可能會導致Redis在一些毫秒級內不能響應客戶端的請求.如果資料集巨大並且CPU效能不是很好的情況下,這種情況會持續1秒,AOF也需要fork,但是你可以調節重寫日誌檔案的頻率來提高資料集的耐久度

  • 優點：

    • 適合大規模的資料恢復
    • 持久化速度快，相對AOF來說：資料安全（ 二進位制檔案嘛 ）

—————————————————————官方話如下：—————————————————————————————

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

2、AOF

2.1）、什麼是AOF

  • 全稱：append only file
  • AOF是Redis進行持久化的另外一種操作方式

2.2）、配置AOF

2.2.1）、編寫redis.conf檔案

截圖

  • 編寫內容如下：

# 配置AOF
appendonly yes
appendfilename redis.aof
appendfsync everysec

# 下面這兩個是另外一種配置措施，一般都不考慮
# appendfsync always
# # appendfsync no
  • appendfsync always：每執行一個寫操作，立即持久化到AOF檔案中，效能比較低
  • appendfsync everysec：每秒執行一次持久化
  • appendfsync no：會根據你的作業系統不同，環境的不同，在一定時間內執行一次持久化

2.2.2）、重啟Redis即可

  • 重啟之後，測試如下：
    截圖

截圖

2.2.3）、檢查資料卷對映的檔案目錄

截圖

  • 可見：多出了 .aof檔案

  • 檢視一下這個 aof檔案
    截圖

    • 發現：這個aof檔案中儲存的就是我們剛剛在redis中儲存key-value時的指令

  • 還是老話，前面這些不是老衲想說的，下面的才是老衲準備說的內容

2、AOF的原理

截圖

3、AOF的觸發條件

  • 一句話：只要配置了，那麼只要啟動Redis就會觸發（ 可以把aof檔案刪掉，然後重啟Redis，再看對映檔案路徑，就會發現有了aof檔案 ）

4、AOF的優缺點

  • 缺點：

    • 資料恢復慢（ 大資料時，它是去重新執行一遍aof檔案中的資料 ，它存的是指令，是一個文字檔案，大資料時，這就會變得很大 ，但是：）
      截圖

      • 可以加入這個配置，從而限定：內容超過多大之後，就另起一個aof檔案來記錄內容[專業詞：重寫]（ 重新寫一個aof檔案 ）

—————————————————————官方話如下：—————————————————————————————

  • 對於相同的資料集來說，AOF 檔案的體積通常要大於 RDB 檔案的體積

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

  • 優點：

    • 採用每修改一次key就同步的話，資料的完整性比較好
    • 採用每秒同步一次的話，持久化也快，注：容易丟失這一秒的資料，對照RDB來看
    • 採用從不同步的話，效率蠻高，但是：不建議

—————————————————————官方話如下：—————————————————————————————

  • 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記錄的是每次寫操作，讀操作並不會記錄滴

3、建議

  • 同時開啟rdb和aof
    截圖

  • 同時開啟RDB和AOF的注意事項：

    • 如果同時開啟了AOF和RDB持久化，那麼在Redis當機重啟之後，需要載入一個持久化檔案，優先選擇AOF檔案。
    • 如果先開啟了RDB，再次開啟AOF，如果RDB執行了持久化，那麼RDB檔案中的內容會被AOF覆蓋掉。

相關文章