redis aof和rdb區別

來源:互聯網
上載者:User

標籤:變化   一致性   指定   web   key   的區別   共用   刪除   解決   

轉自76906422

1、前言

最近在項目中使用到Redis做緩衝,方便多個業務進程之間共用資料。由於Redis的資料都存放在記憶體中,如果沒有配置持久化,redis重啟後資料就全丟失了,於是需要開啟redis的持久化功能,將資料儲存到磁碟上,當redis重啟後,可以從磁碟中恢複資料。redis提供兩種方式進行持久化,一種是RDB持久化(原理是將Reids在記憶體中的資料庫記錄定時dump到磁碟上的RDB持久化),另外一種是AOF持久化(原理是將Reids的動作記錄以追加的方式寫入檔案)。那麼這兩種持久化方式有什麼區別呢,改如何選擇呢?網上看了大多數都是介紹這兩種方式怎麼配置,怎麼使用,就是沒有介紹二者的區別,在什麼應用情境下使用。

2、二者的區別

RDB持久化是指在指定的時間間隔內將記憶體中的資料集快照寫入磁碟,實際操作過程是fork一個子進程,先將資料集寫入臨時檔案,寫入成功後,再替換之前的檔案,用二進位壓縮儲存。

 

AOF持久化以日誌的形式記錄伺服器所處理的每一個寫、刪除操作,查詢操作不會記錄,以文本的方式記錄,可以開啟檔案看到詳細的操作記錄。

 

3、二者優缺點RDB存在哪些優勢呢?

1). 一旦採用該方式,那麼你的整個Redis資料庫將只包含一個檔案,這對於檔案備份而言是非常完美的。比如,你可能打算每個小時歸檔一次最近24小時的資料,同時還要每天歸檔一次最近30天的資料。通過這樣的備份策略,一旦系統出現災難性故障,我們可以非常容易的進行恢複。

2). 對於災難恢複而言,RDB是非常不錯的選擇。因為我們可以非常輕鬆的將一個單獨的檔案壓縮後再轉移到其它儲存介質上。

3). 效能最大化。對於Redis的服務進程而言,在開始持久化時,它唯一需要做的只是fork出子進程,之後再由子進程完成這些持久化的工作,這樣就可以極大的避免服務進程執行IO操作了。

4). 相比於AOF機制,如果資料集很大,RDB的啟動效率會更高。

RDB又存在哪些劣勢呢?

1). 如果你想保證資料的高可用性,即最大限度的避免資料丟失,那麼RDB將不是一個很好的選擇。因為系統一旦在定時持久化之前出現宕機現象,此前沒有來得及寫入磁碟的資料都將丟失。

2). 由於RDB是通過fork子進程來協助完成資料持久化工作的,因此,如果當資料集較大時,可能會導致整個伺服器停止服務幾百毫秒,甚至是1秒鐘。

AOF的優勢有哪些呢?

1). 該機制可以帶來更高的資料安全性,即資料持久性。Redis中提供了3中同步策略,即每秒同步、每修改同步和不同步。事實上,每秒同步也是非同步完成的,其效率也是非常高的,所差的是一旦系統出現宕機現象,那麼這一秒鐘之內修改的資料將會丟失。而每修改同步,我們可以將其視為同步持久化,即每次發生的資料變化都會被立即記錄到磁碟中。可以預見,這種方式在效率上是最低的。至於無同步,無需多言,我想大家都能正確的理解它。

2). 由於該機制對記錄檔的寫入操作採用的是append模式,因此在寫入過程中即使出現宕機現象,也不會破壞記錄檔中已經存在的內容。然而如果我們本次操作只是寫入了一半資料就出現了系統崩潰問題,不用擔心,在Redis下一次啟動之前,我們可以通過redis-check-aof工具來協助我們解決資料一致性的問題。

3). 如果日誌過大,Redis可以自動啟用rewrite機制。即Redis以append模式不斷的將修改資料寫入到老的磁碟檔案中,同時Redis還會建立一個新的檔案用於記錄此期間有哪些修改命令被執行。因此在進行rewrite切換時可以更好的保證資料安全性。

4). AOF包含一個格式清晰、易於理解的記錄檔用於記錄所有的修改操作。事實上,我們也可以通過該檔案完成資料的重建。

AOF的劣勢有哪些呢?

1). 對於相同數量的資料集而言,AOF檔案通常要大於RDB檔案。RDB 在恢複大資料集時的速度比 AOF 的恢複速度要快。

2). 根據同步策略的不同,AOF在運行效率上往往會慢於RDB。總之,每秒同步策略的效率是比較高的,同步禁用策略的效率和RDB一樣高效。

二者選擇的標準,就是看系統是願意犧牲一些效能,換取更高的緩衝一致性(aof),還是願意寫操作頻繁的時候,不啟用備份來換取更高的效能,待手動運行save的時候,再做備份(rdb)。rdb這個就更有些 eventually consistent的意思了。

4、常用配置RDB持久化配置

Redis會將資料集的快照dump到dump.rdb檔案中。此外,我們也可以通過設定檔來修改Redis伺服器dump快照的頻率,在開啟6379.conf檔案之後,我們搜尋save,可以看到下面的配置資訊:

save 900 1              #在900秒(15分鐘)之後,如果至少有1個key發生變化,則dump記憶體快照。

save 300 10            #在300秒(5分鐘)之後,如果至少有10個key發生變化,則dump記憶體快照。

save 60 10000        #在60秒(1分鐘)之後,如果至少有10000個key發生變化,則dump記憶體快照。

AOF持久化配置

在Redis的設定檔中存在三種同步方式,它們分別是:

appendfsync always     #每次有資料修改發生時都會寫入AOF檔案。

appendfsync everysec  #每秒鐘同步一次,該策略為AOF的預設策略。

appendfsync no          #從不同步。高效但是資料不會被持久化。

5、參考資料

http://blog.csdn.net/jackpk/article/details/30073097

http://www.jb51.net/article/65264.htm

redis aof和rdb區別

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.