redis 持久化RDB、AOF

一、redis持久化簡介

Redis是一種高級key-value數據庫。它跟memcached相似，不過數據能夠持久化，並且支持的數據類型很豐富。有字符串，鏈表，集合和有序集合。支持在服務器端計算集合的並，交和補集(difference)等，還支持多種排序功能。因此Redis也能夠被當作是一個數據結構服務 器。

Redis的全部數據都是保存在內存中，而後不按期的經過異步方式保存到磁盤上(這稱爲「半持久化模式」)；也能夠把每一次數據變化都寫入到一個append only file(aof)裏面(這稱爲「全持久化模式」)。 

因爲Redis的數據都存放在內存中，若是沒有配置持久化，redis重啓後數據就全丟失了，因而須要開啓redis的持久化功能，將數據保存到磁盤上，當redis重啓後，能夠從磁盤中恢復數據。redis提供兩種方式進行持久化，一種是RDB持久化（原理是將Reids在內存中的數據庫記錄定時dump到磁盤上的RDB持久化），另一種是AOF（append only file）持久化（原理是將Reids的操做日誌以追加的方式寫入文件）

Redis 提供了多種不一樣級別的持久化方式：

• RDB 持久化能夠在指定的時間間隔內生成數據集的時間點快照（point-in-time snapshot）。
• AOF 持久化記錄服務器執行的全部寫操做命令，並在服務器啓動時，經過從新執行這些命令來還原數據集。 AOF 文件中的命令所有以 Redis 協議的格式來保存，新命令會被追加到文件的末尾。 Redis 還能夠在後臺對 AOF 文件進行重寫（rewrite），使得 AOF 文件的體積不會超出保存數據集狀態所需的實際大小。
• Redis 還能夠同時使用 AOF 持久化和 RDB 持久化。 在這種狀況下， 當 Redis 重啓時， 它會優先使用 AOF 文件來還原數據集， 由於 AOF 文件保存的數據集一般比 RDB 文件所保存的數據集更完整。
• 你甚至能夠關閉持久化功能，讓數據只在服務器運行時存在。

二、兩者的區別

RDB持久化是指在指定的時間間隔內將內存中的數據集快照寫入磁盤，實際操做過程是fork一個子進程，先將數據集寫入臨時文件，寫入成功後，再替換以前的文件，用二進制壓縮存儲。

 

AOF持久化以日誌的形式記錄服務器所處理的每個寫、刪除操做，查詢操做不會記錄，以文本的方式記錄，能夠打開文件看到詳細的操做記錄。

三、兩者優缺點

　　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的意思了。

四、經常使用配置

　　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 #從不一樣步。高效可是數據不會被持久化。