Redis持久化介紹

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文件的內容壓縮。

作者:張文博

其他討論

4大步驟節省30%浪費,優化企業上雲成本從瞭解雲開始!

運維思考 | 你知道CMDB與監控是什麼關係嗎?

【乾貨】4種Oracle DBaaS部署模式,你在使用哪一種?

如何改善監控問題,試試打造企業統一監控平臺體系!

雲計算 | 數據在雲上安全嗎?DDoS攻擊怎麼辦?

發佈了93 篇原創文章 · 獲贊 26 · 訪問量 5萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章