Redis持久化的運行機制和優(yōu)缺點是什么

Redis持久化的運行機制和優(yōu)缺點是什么，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

前言

大家都知道Redis一個內(nèi)存數(shù)據(jù)庫,它支持2種持久化方式：RDB(Snapshot 內(nèi)存快照) ，AOF(append only file)。持久化功能將內(nèi)存中的數(shù)據(jù)同步到磁盤來避免Redis發(fā)生異常導致數(shù)據(jù)丟失的情況。當Redis實例重啟時，即可利用之前持久化的文件實現(xiàn)數(shù)據(jù)恢復。

接下來，小編介紹兩種持久化的運行機制和優(yōu)缺點。

一 RDB

RDB是默認的持久化方式，按照一定的策略周期性的將內(nèi)存中的數(shù)據(jù)生成快照保存到磁盤。

每次快照持久化都是將內(nèi)存數(shù)據(jù)完整寫入到磁盤一次，并不 是增量的只同步臟數(shù)據(jù)。如果數(shù)據(jù)量大的話，而且寫操作比較多，必然會引起大量的磁盤io操作，可能會嚴重影響性能。

1.1 快照持久化過程

1.2 觸發(fā)機制

1. save 命令

當客戶端向Redis server發(fā)送save命令請求進行持久化時，由于Redis是用一個主線程來處理所有,save命令會阻塞Redis server處理其他客戶端的請求，直到數(shù)據(jù)同步完成。

2. bgsave命令

與save命令不同，bgsave是異步執(zhí)行的，當執(zhí)行bgsave命令之后，Redis主進程會fork 一個子進程將數(shù)據(jù)保存到rdb文件中，同步完數(shù)據(jù)之后，對原有文件進行替換，然后通知主進程表示同步完成。

3. 自動觸發(fā)

除了手動觸發(fā)RDB持久化，Redis內(nèi)部還存在自動觸發(fā)機制，

在配置中集中配置 save m n 的方式，表示 m秒內(nèi)數(shù)據(jù)集存在n次修改時，系統(tǒng)自動觸發(fā)bgsave 操作。 

# 900s內(nèi)至少達到一條寫命令      save 900 1      # 300s內(nèi)至少達至10條寫命令      save 300 10      # 60s內(nèi)至少達到10000條寫命令      save 60 10000

從節(jié)點執(zhí)行全量復制操作，主節(jié)點自動執(zhí)行bgsave 生成RDB文件并發(fā)送給從節(jié)點

默認情況下執(zhí)行 shutdown 命令時，如果沒有開啟AOF持久化功能，系統(tǒng)會自動執(zhí)行bgsave命令。執(zhí)行debug reload 命令重新加載Redis時，也會自動觸發(fā)save操作。

1.3 相關參數(shù) 

# 持久化 rdb文件遇到問題時，主進程是否接受寫入，yes 表示停止寫入，如果是no 表示redis繼續(xù)提供服務。      stop-writes-on-bgsave-error yes      # 在進行快照鏡像時,是否進行壓縮。yes:壓縮，但是需要一些cpu的消耗。no:不壓縮，需要更多的磁盤空間。      rdbcompression yes      # 一個CRC64的校驗就被放在了文件末尾，當存儲或者加載rbd文件的時候會有一個10%左右的性能下降，為了達到性能的最大化，你可以關掉這個配置項。      rdbchecksum yes      # 快照的文件名      dbfilename dump.rdb      # 存放快照的目錄      dir /var/lib/redis

1.4 RDB的優(yōu)缺點

優(yōu)點

RDB文件小，非常適合定時備份，用于災難恢復。

因為RDB文件中直接存儲的是內(nèi)存數(shù)據(jù)，而AOF文件中存儲的是一條條命令，需要應用命令。Redis加載RDB文件的速度比AOF快很多。

缺點

RDB持久化方式不能做到實時/秒級持久化。實時持久化要全量刷內(nèi)存到磁盤，成本太高。每秒fork子進程也會阻塞主進程，影響性能。

RDB文件是二進制文件，隨著Redis不斷迭代有多個rdb文件的版本，不支持跨版本兼容。老的Redis無法識別新的RDB文件格式。

二 AOF

AOF(Append-only file)針對RDB的缺點做了優(yōu)化，在使用AOF持久化方式時，Redis會將每一個收到的寫操作命令都通過Write函數(shù)追加到文件最后，類似于MySQL的binlog。當Redis重啟時會通過重新執(zhí)行文件中保存的寫命令來在內(nèi)存中重建整個數(shù)據(jù)庫的內(nèi)容。

2.1 AOF持久化過程

1. 客戶端發(fā)出 bgrewriteaof命令。

2. redis主進程fork子進程。

3. 父進程繼續(xù)處理client請求，除了把寫命令寫入到原來的aof文件中。同時把收到的寫命令緩存到 AOF重寫緩沖區(qū)。這樣就能保證如果子進程重寫失敗的話并不會出問題。

4. 子進程根據(jù)內(nèi)存快照，按照命令合并規(guī)則寫入到新AOF文件中。

5. 當子進程把內(nèi)存快照寫入臨時文件中后，子進程發(fā)信號通知父進程。然后父進程把緩存的寫命令也寫入到臨時文件。

6. 現(xiàn)在父進程可以使用臨時文件替換老的aof文件，并重命名，后面收到的寫命令也開始往新的aof文件中追加。

2.2 相關參數(shù) 

# 是否開啟AOF，默認關閉      appendonly yes      # 指定 AOF 文件名      appendfilename appendonly.aof      # Redis支持三種刷寫模式：      # appendfsync always #每次收到寫命令就立即強制寫入磁盤，類似MySQL的sync_binlog=1,是最安全的。但該模式下速度也是最慢的，一般不推薦使用。      appendfsync everysec #每秒鐘強制寫入磁盤一次，在性能和持久化方面做平衡，推薦該方式。      # appendfsync no     #完全依賴OS的寫入，一般為30秒左右一次，性能最好但是持久化最沒有保證，不推薦。      #在日志重寫時，不進行命令追加操作，而只是將其放在緩沖區(qū)里，避免與命令的追加造成DISK IO上的沖突。      #設置為yes表示rewrite期間對新寫操作不fsync,暫時存在內(nèi)存中,等rewrite完成后再寫入，默認為no，建議yes      no-appendfsync-on-rewrite yes      #當前AOF文件大小是上次日志重寫得到AOF文件大小的二倍時，自動啟動新的日志重寫過程。      auto-aof-rewrite-percentage 100      #當前AOF文件啟動新的日志重寫過程的最小值，避免剛剛啟動Reids時由于文件尺寸較小導致頻繁的重寫。      auto-aof-rewrite-min-size 64mb

2.3 日志重寫

AOF機制將客戶端的每一個寫操作都追加到aof文件末尾，比如將一個key多次執(zhí)行incr,set命令,會寫入多次命令到aof文件，aof文件會越來越大，部分核心業(yè)務每天的寫入量有幾十G的大小。 

incr k1 1     set  k2 a     set  k2 b     incr k1 2     incr k1 3    set  k2 c     del  k3     ...     incr k1 100

恢復Redis實例時，加載非常大的aof文件耗時會很長。為了解決這個問題，Redis 支持aof文件重寫--把Redis進程內(nèi)的數(shù)據(jù)轉(zhuǎn)化為寫命令同步到新AOF文件中的過程。通過重寫，可以生成一個最小的命令集合。比如上面的幾個命令可以合并為

incr k1 100    set  k2 c

寫入數(shù)據(jù)的規(guī)則

1. 進程內(nèi)過期的數(shù)據(jù)不用在寫入

2. 舊AOF文件含有的無效命令 del k1, set a 1, set a 2。重寫使用進程內(nèi)的數(shù)據(jù)直接生成，aof文件就保留最新的命令集合。

3. 多條命令可以合并為一個命令，為了防止單個命令過大造成客戶端緩沖區(qū)溢出，對于list,set,hash,zset 等類型的操作，以64個元素為界拆分為多條。

觸發(fā)機制

1. 手動觸發(fā) 執(zhí)行bgrewriteaof命令。

2. 根據(jù)配置自動觸發(fā)

auto-aof-rewrite-min-size 表示運行AOF重寫是文件最小的大小。默認64M，小于64M就會不自動重寫了。

auto-aof-rewrite-percentage 表示（aof_current_size- aof_base_size） / aof_base_size 的比值。

aof文件重寫之后當前文件大小增長多少就觸發(fā)重寫

自動觸發(fā)時機 :

aof_current_size>auto-aof-rewrite-min-size

&&

(aof_current_size - aof_base_size) /  aof_base_size >= auto-aof-rewrite-percentage

三 RDB VS AOF 對比

具體使用哪種持久化方式 ，下面是來自官方的建議：

通常，如果你要想提供很高的數(shù)據(jù)保障性，那么建議你同時使用兩種持久化方式。如果你可以接受災難帶來的幾分鐘的數(shù)據(jù)丟失，那么你可以僅使用RDB。很多用戶僅使用了AOF，但是我們建議，既然RDB可以時不時的給數(shù)據(jù)做個完整的快照，并且提供更快的重啟，所以最好還是也使用RDB。

生產(chǎn)上的實例大多不會是單點，而是主從，也有利用slave作為持久化方式，同時滿足HA的需求。讀者朋友可以分享一下各自遇到的和 redis 持久化相關的問題。

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業(yè)資訊頻道，感謝您對億速云的支持。