共計 2733 個字符，預計需要花費 7 分鐘才能閱讀完成。

自動寫代碼機器人，免費開通

丸趣 TV 小編給大家分享一下 redis 如何進行持久化，希望大家閱讀完這篇文章之后都有所收獲，下面讓我們一起去探討吧！

1、redis 簡介

REmote DIctionary Server(Redis) 是一個由 Salvatore Sanfilippo 寫的 key-value 存儲系統。

Redis 是一個開源的使用 ANSI C 語言編寫、遵守 BSD 協議、支持網絡、可基于內存亦可持久化的日志型、Key-Value 數據庫，并提供多種語言的 API。

它通常被稱為數據結構服務器，因為值（value）可以是 字符串 (String), 哈希(Hash), 列表(list), 集合(sets) 和 有序集合(sorted sets) 等類型。

它跟 memcached 類似，不過數據可以持久化，而且支持的數據類型很豐富。有字符串，鏈表，集 合和有序集合。支持在服務器端計算集合的并，交和補集 (difference) 等，還支持多種排序功能。所以 Redis 也可以被看成是一個數據結構服務器。

Redis 的所有數據都是保存在內存中，然后不定期的通過異步方式保存到磁盤上 (這稱為“半持久化模式”)；也可以把每一次數據變化都寫入到一個 append only file(aof) 里面(這稱為“全持久化模式”)。

由于 Redis 的數據都存放在內存中，如果沒有配置持久化，redis 重啟后數據就全丟失了，于是需要開啟 redis 的持久化功能，將數據保存到磁盤上，當 redis 重啟后，可以從磁盤中恢復數據。redis 提供兩種方式進行持久化，一種是 RDB 持久化（原理是將 Reids 在內存中的數據庫記錄定時 dump 到磁盤上的 RDB 持久化），另外一種是 AOF（append only file）持久化（原理是將 Reids 的操作日志以追加的方式寫入文件）。那么這兩種持久化方式有什么區別呢，改如何選擇呢？網上看了大多數都是介紹這兩種方式怎么配置，怎么使用，就是沒有介紹二者的區別，在什么應用場景下使用。

2、二者的區別

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

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

看完了這篇文章，相信你對“redis 如何進行持久化”有了一定的了解，如果想了解更多相關知識，歡迎關注丸趣 TV 行業資訊頻道，感謝各位的閱讀！