技術文章 » Redis持久化機制和如何實現持久化

Redis持久化機制和如何實現持久化

2020-10-11 11:00:48

一. Redis持久化概述

Redis的高效能是由於其將所有資料都儲存在了記憶體中,為了使Redis在重新啟動之後仍能保證資料不丟失,需要將資料從記憶體中同步到硬碟中,這一過程就是持久化. Redis支援兩種方式的持久化,一種是RDB(Redis Database)方式,一種是AOF(Append Only File)方式. 可以單獨使用其中一種或將二者結合使用

  • RDB持久化(預設)
    該機制是指在指定的時間間隔內將記憶體中的資料集快照寫入磁碟
  • AOF持久化
    該機制將以紀錄檔的形式記錄伺服器所處理的每一個寫操作,在Redis伺服器啟動之初會讀取該檔案來重新構建資料庫,以保證啟動後資料庫中的資料是完整的
  • 無持久化
    可以通過設定的方式禁用Redis伺服器的持久化功能,這樣我們就可以將Redis視為一個功能加強版的memcached了
  • redis可以同時使用RDB和AOF

二. RDB持久化機制

1. RDB持久化機制優點

  • 一旦採用該方式,那麼你的整個Redis資料庫將只包含一個檔案,這對於檔案備份來說是很完美的. 比如,你可能打算每個小時歸檔一次最近24小時的資料,同時還要每天歸檔一次近30天的資料. 通過這樣的備份策略,一旦系統出現故障,我們可以非常容易進行恢復
  • 對於災難恢復而言,RDB是非常不錯的選擇. 因為我們可以非常輕鬆的將一個單獨的檔案壓縮後再轉移到其他儲存媒介上
  • 效能最大化. 對於Redis的服務程序而言,在開始持久化時,它唯一需要做的就是fork出子程序,之後再由子程序完成持久化操作,這樣就能極大的避免服務程序進行IO操作了

相比於AOF,如果資料集很大,RDB的啟動效率會更高

2. RDB持久化機制缺點

  • 如果你想保證資料的高可用性,即最大限度的保證資料不丟失,那麼RDB就不是一個很好的選擇,因為系統在即將定時持久化之前宕機,此時沒有來的及寫入磁碟的資料將全部丟失
  • 由於RDB是通過fork出子程序來協助完成資料持久化工作的,因此,當資料集較大時,可能會導致整個伺服器停止服務幾百毫秒,甚至1sec

3. RDB持久化機制設定

在redis.windows.conf組態檔中有如下設定:

################################ SNAPSHOTTING #################################
# #
Save the DB on disk:
# #
save <seconds> <changes>
# #
Will save the DB if both the given number of seconds and the given
# number of write operations against the DB occurred.
# #
In the example below the behaviour will be to save:
# after 900 sec (15 min) if at least 1 key changed
# after 300 sec (5 min) if at least 10 keys changed
# after 60 sec if at least 10000 keys changed
# #
Note: you can disable saving at all commenting all the "save" lines.
# #
It is also possible to remove all the previously configured save
# points by adding a save directive with a single empty string argument
# like in the following example:
# #
save ""
save 900 1
save 300 10
save 60 10000

其中,上面設定的是RDB方式資料持久化時機:

關鍵字時間(Sec)key修改量解釋
save9001每900秒(15分鐘)至少有1個key發生變化,則dump記憶體快照
save30010每300秒(5分鐘)至少有10個key發生變化，則dump記憶體快照
save6010000每60秒(1分鐘)至少有10000個key發生變化，則dump記憶體快照

三. AOF持久化機制

1. AOF持久化機制優點

  • 該機制可以帶來更高的資料安全性,即資料永續性. Redis中提供了3中同步策略,即每秒同步、每修改同步和不同步. 事實上，每秒同步也是非同步完成的,其效率也是非常高的,所差的是一旦系統出現宕機現象,那麼這一秒鐘之內修改的資料將會丟失. 而每修改同步,我們可以將其視為同步持久化,即每次發生的資料變化都會被立即記錄到磁碟中. 可以預見, 這種方式在效率上是最低的. 至於無同步,無需多言,大家都能夠理解
  • 由於該機制對紀錄檔檔案的寫入操作採用的是append模式,因此在寫入過程中即使出現宕機現象,也不會破壞紀錄檔檔案中已經存在的內容. 然而如果我們本次操作只是寫入了一半資料就出現了系統崩潰問題,不用擔心,在Redis下一次啟動之前,我們可以通過redis-check-aof工具來幫助我們解決資料一致性的問題
  • 如果紀錄檔過大,Redis可以自動啟用rewrite機制. 即Redis以append模式不斷的將修改資料寫入到老的磁碟檔案中,同時Redis還會建立一個新的檔案用於記錄此期間有哪些修改命令被執行. 因此在進行rewrite切換時可以更好的保證資料安全性
  • AOF包含一個格式清晰、易於理解的紀錄檔檔案用於記錄所有的修改操作. 事實上,我們也可以通過該檔案完成資料的重建

2. AOF持久化機制缺點

  • 對於相同數量的資料集而言,AOF檔案通常要大於RDB檔案
  • 根據同步策略的不同,AOF在執行效率上往往會慢於RDB. 總之,每秒同步策略的效率是比較高的,同步禁用策略的效率和RDB一樣高效

3. AOF持久化機制設定

  • 開啟AOF持久化
############################## APPEND ONLY MODE ###############################
# By default Redis asynchronously dumps the dataset on disk. This mode is
# good enough in many applications, but an issue with the Redis process or
# a power outage may result into a few minutes of writes lost (depending on
# the configured save points)
# #
The Append Only File is an alternative persistence mode that provides
# much better durability. For instance using the default data fsync policy
# (see later in the config file) Redis can lose just one second of writes in a
# dramatic event like a server power outage, or a single write if something
# wrong with the Redis process itself happens, but the operating system is
# still running correctly.
# #
AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.
# #
Please check http://redis.io/topics/persistence for more information.
appendonly no

將appendonly修改為yes,開啟aof持久化機制,預設會在目錄下產生一個appendonly.aof檔案

  • AOF持久化時機
# appendfsync always
appendfsync everysec
# appendfsync no

上述設定為aof持久化的時機,解釋如下:

關鍵字持久化時機解釋
appendfsyncalways每執行一次更新命令,持久化一次
appendfsynceverysec每秒鐘持久化一次
appendfsyncno不會主動執行持久化,依賴於作業系統的空閒呼叫

四. 兩種持久化方式對比

命令RDBAOF
啟動優先順序低高
體積小大
恢復速度快慢
資料安全性丟資料根據策略決定
輕重重輕