Redis持久化介紹

  • 2019 年 12 月 18 日
  • 筆記

Redis是一個基於BSD開源許可的記憶體數據結構存儲系統,由於redis具有卓越的高並發讀寫特性,其主要用於用作資料庫、快取和消息代理。redis具有內置的複製、lua、lru、事務和不同級別的磁碟持久性,並通過哨兵機制和集群自動分區功能提供高可用性。本文主要介紹包含RDB(Redis DataBase)持久化、AOF(Append Only File)持久化、RDB和AOF混合持久化等持久化策略。

Redis以下幾種持久性選項範圍:

  • RDB持久性按指定的時間間隔執行數據集的時間點快照。
  • AOF持久性會記錄伺服器接收的每個寫入操作,這些操作將在伺服器啟動時再次播放,以重建原始數據集。使用與Redis協議本身相同的格式記錄命令,並且採用僅追加方式。當日誌太大時,Redis可以在後台重寫日誌。
  • 可以在同一實例中同時合併AOF和RDB。在這種情況下,當Redis重新啟動時,AOF文件將用於重建原始數據集,因為它可以保證是最完整的。
  • 如果希望只用作快取伺服器,對數據的持久性無要求,也可以完全禁用持久性。

下面著重介紹RDB和AOF持久化的特點和應用場景。

RDB持久化

RDB持久化的優點

RDB 是 Redis 默認的持久化方案。在指定的時間間隔內,寫操作達到指定的次數,則會將記憶體中的數據寫入到磁碟RDB文件中。由於RDB文件是一個非常緊湊的文件,比較容易備份,所以RDB對於災難恢復非常有用。RDB最大限度地提高了Redis的性能,因為Redis父進程的持久化操作是通過分叉子進程實現,而父進程不會執行磁碟I / O等操作。與AOF相比,RDB允許大型數據集更快地重啟。

RDB持久化的缺點

RDB持久化的寫入方式決定了該持久化策略並不能完全保證數據的安全性。RDB需要經常使用fork()才能使用子進程將其持久化在磁碟上。如果數據集很大,Fork()可能很耗時,並且如果數據集很大且CPU性能不佳,則可能導致Redis停止為客戶端服務幾毫秒甚至一秒鐘。該過程如果出現宕機,則可能造成數據丟失。

RDB持久化配置

打開 redis.conf 文件,定位到 SNAPSHOTTING 對應內容

save <seconds> <changes>

# save ""

save 900 1

save 300 10

save 60 10000

dbfilename dump.rdb

dir ./

rdbcompression yes

save <指定時間間隔> <執行指定次數更新操作>,滿足條件就將記憶體中的數據同步到硬碟中。官方出廠配置默認是 900秒內有1個更改,300秒內有10個更改以及60秒內有10000個更改,則將記憶體中的數據快照寫入磁碟。關閉RDB,則把上面配置注釋即可。

  • dbfilename指定本地資料庫文件名,默認文件名為 dump.rdb,文件格式.rdb結尾。
  • dir指定資料庫存放目錄為當前目錄
  • rdbcompression開啟數據壓縮,默認為yes,Redis採用LZF壓縮方式。

RDB的觸發與恢復

觸發RDB快照的方式有save策略觸發,flush命令(清空資料庫所有數據),shutdown(關閉redis)命令,三種方式都是調用redis的bgsave機制實現快照觸發。

RDB文件恢複數據的方式是將dump.rdb 文件拷貝到redis的安裝目錄的bin目錄下,重啟redis服務即可。

AOF持久化

AOF持久化的優勢

AOF可以彌補RDB的不足(數據的不一致性),它採用日誌的形式來記錄每個寫操作,並追加到文件中。Redis 重啟的會根據日誌文件的內容將寫指令從前到後執行一次以完成數據的恢復工作。

使用AOF Redis更加持久,提供不同的fsync策略:完全沒有fsync,每秒fsync,每個查詢fsync。使用默認策略fsync時,每秒的寫入性能仍然很好(fsync是使用後台執行緒執行的,並且在沒有進行fsync的情況下,主執行緒將儘力執行寫入操作。)

AOF日誌是僅追加的日誌,因此即便是斷電故障,也不會出現磁碟尋道或損壞問題。即使由於某種原因(磁碟已滿或其他)導致日誌錯誤,也可以使用redis-check-aof工具=輕鬆修復。

AOF持久化的缺點

對於同一數據集,AOF文件通常大於等效的RDB文件。在特定的fsync策略下,AOF比RDB的效率低。通常,在將fsync設置為每秒的情況下,性能仍然很高,並且在禁用fsync的情況下,即使在高負載下,它也應與RDB一樣快。即使在巨大的寫負載的情況下,RDB仍然能夠提供有關最大延遲的更多保證。但是如果fsync策略為aways,則隨著集群負載增大,AOF記錄的內容越來越大多,文件會越來越大,數據恢復也會越來越慢。

AOF持久化配置

打開 redis.conf 文件,定位到APPEND ONLY MODE 對應內容

appendonly yes

appendfilename "appendonly.aof"

appendfsync everysec

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

說明:

  • appendonly 配置redis 默認關閉,開啟需要手動把no改為yes
  • appendfilename指定本地資料庫文件名,默認值為 appendonly.aof
  • appendfsync everysec指定更新日誌條件為每秒更新,共三種策略(aways,everyse,no)
  • auto-aof-rewrite-min-size配置重寫觸發機制,當AOF文件大小是上次rewrite後大小的一倍且文件大於64M時觸發。

AOF觸發與恢復

AOF主要根據配置文件策略觸發,可以是每次執行觸發,可以是每秒觸發,可以不同步。

AOF的恢復主要是將appendonly.aof 文件拷貝到redis的安裝目錄的bin目錄下,重啟redis服務即可。但在實際開發中,可能因為某些原因導致appendonly.aof 文件異常,從而導致數據還原失敗,可以通過命令redis-check-aof –fix appendonly.aof 進行修復

AOF的工作原理是將寫操作追加到文件中,文件的冗餘內容會越來越多。所以Redis 新增了重寫機制,通過auto-aof-rewrite-min-size控制。當AOF文件的大小超過所設定的閾值時,Redis就會對AOF文件的內容壓縮。