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

一. 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方式資料持久化時機:

三. 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持久化的時機,解釋如下:

四. 兩種持久化方式對比