本篇內容介紹了“什么是redis持久化”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

成都創(chuàng)新互聯(lián)專注于晉城企業(yè)網(wǎng)站建設,成都響應式網(wǎng)站建設,成都商城網(wǎng)站開發(fā)。晉城網(wǎng)站建設公司,為晉城等地區(qū)提供建站服務。全流程按需定制制作，專業(yè)設計，全程項目跟蹤，成都創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務

• RDB：快照形式是直接把內存中的數(shù)據(jù)保存到一個 dump 文件中，恢復時是將快照文件直接讀到內存里。

• AOF：把所有的對Redis的服務器進行修改的命令都存到一個文件里，命令的集合。

Redis默認是快照RDB的持久化方式

RDB

RDB 有兩種觸發(fā)方式，分別是自動觸發(fā)和手動觸發(fā)

• 自動觸發(fā)

  在 redis.conf 配置文件中的 SNAPSHOTTING 下，加上如下配置：

  save 900 1：表示900 秒內如果至少有 1 個 key 的值變化，則保存
  save 300 10：表示300 秒內如果至少有 10 個 key 的值變化，則保存
  save 60 10000：表示60 秒內如果至少有 10000 個 key 的值變化，則保存

  當然如果你只是用Redis的緩存功能，不需要持久化，那么你可以注釋掉所有的 save 行來停用保存功能，也可以使用`redis-cli config set save ""命令

• 手動觸發(fā)

  手動觸發(fā)Redis進行RDB持久化的命令有兩種：

1. save

   該命令會阻塞當前Redis服務器，執(zhí)行save命令期間，Redis不能處理其他命令，直到RDB過程完成為止

2. bgsave

   執(zhí)行該命令時，Redis會在后臺異步進行快照操作，快照同時還可以響應客戶端請求。具體操作是Redis進程執(zhí)行fork操作創(chuàng)建子進程，RDB持久化過程由子進程負責，完成后自動結束。阻塞只發(fā)生在fork階段，一般時間很短

基本上 Redis 內部所有的RDB操作都是采用 bgsave 命令

恢復數(shù)據(jù)

將備份文件 (dump.rdb) 移動到 redis 安裝目錄并啟動服務即可，redis就會自動加載文件數(shù)據(jù)至內存了。Redis 服務器在載入 RDB 文件期間，會一直處于阻塞狀態(tài)，直到載入工作完成為止。

獲取 redis 的安裝目錄可以使用 config get dir 命令

RDB優(yōu)勢與劣勢

優(yōu)勢：

• RDB是一個非常緊湊(compact)的文件，它保存了redis 在某個時間點上的數(shù)據(jù)集。這種文件非常適合用于進行備份和災難恢復

• 生成RDB文件的時候，redis主進程會fork()一個子進程來處理所有保存工作，主進程不需要進行任何磁盤IO操作

• RDB 在恢復大數(shù)據(jù)集時的速度比 AOF 的恢復速度要快

劣勢：

• RDB方式數(shù)據(jù)沒辦法做到實時持久化/秒級持久化。因為bgsave每次運行都要執(zhí)行fork操作創(chuàng)建子進程，屬于重量級操作(內存中的數(shù)據(jù)被克隆了一份，大致2倍的膨脹性需要考慮)，頻繁執(zhí)行成本過高(影響性能)

• RDB文件使用特定二進制格式保存，Redis版本演進過程中有多個格式的RDB版本，存在老版本Redis服務無法兼容新版RDB格式的問題(版本不兼容)

• 在一定間隔時間做一次備份，所以如果redis意外down掉的話，就會丟失最后一次快照后的所有修改(數(shù)據(jù)有丟失)

AOF

AOF配置

在 redis.conf 配置文件的 APPEND ONLY MODE 下：

• appendonly no默認配置，表示不開啟AOF持久化

• appendfilename “appendonly.aof”AOF日志文件名

• appendfsync：aof持久化策略的配置；

• no表示不執(zhí)行fsync，由操作系統(tǒng)保證數(shù)據(jù)同步到磁盤，速度最快，但是不太安全；

• always表示每次寫入都執(zhí)行fsync，以保證數(shù)據(jù)同步到磁盤，效率很低；

• everysec表示每秒執(zhí)行一次fsync，可能會導致丟失這1s數(shù)據(jù)。通常選擇 everysec ，兼顧安全性和效率

AOF文件恢復

重啟 Redis 之后就會進行 AOF 文件的載入

AOF重寫

AOF文件不斷變大，Redis為了解決這種情況，在文件大小達到一定閾值后，進行AOF重寫，對AOF文件進行壓縮，只保留可以恢復數(shù)據(jù)的最小指令集

舉個例子：

sadd key "A" "B" "C"

如果不重寫會保留三條sadd指令，但是重寫只會保留一條

• 執(zhí)行AOF重寫的時候，會直接讀取服務器內存的所有鍵值對，不是對之前的AOF文件進行整理

• 子進程進行 AOF 重寫期間，服務器進程（父進程）可以繼續(xù)處理其他命令

• 子進程帶有父進程的數(shù)據(jù)副本，使用子進程而不是線程，可以在避免使用鎖的情況下，保證數(shù)據(jù)的安全性

主進程和子進程之前可能會產生數(shù)據(jù)不一致，解決方案：

Redis 服務器設置了一個 AOF 重寫緩沖區(qū)，這個緩沖區(qū)是在創(chuàng)建子進程后開始使用，當Redis服務器執(zhí)行一個寫命令之后，就會將這個寫命令也發(fā)送到 AOF 重寫緩沖區(qū)。當子進程完成 AOF 重寫之后，就會給父進程發(fā)送一個信號，父進程接收此信號后，就會調用函數(shù)將 AOF 重寫緩沖區(qū)的內容都寫到新的 AOF 文件中

AOF優(yōu)缺點

優(yōu)點：

• AOF 持久化的方法提供了多種的同步頻率，即使使用默認的同步頻率每秒同步一次，Redis 最多也就丟失 1 秒的數(shù)據(jù)而已

• AOF 文件使用 Redis 命令追加的形式來構造，因此，即使 Redis 只能向 AOF 文件寫入命令的片斷，使用 redis-check-aof 工具也很容易修正 AOF 文件

• AOF 文件的格式可讀性較強，這也為使用者提供了更靈活的處理方式。例如，如果我們不小心錯用了 FLUSHALL 命令，在重寫還沒進行時，我們可以手工將最后的 FLUSHALL 命令去掉，然后再使用 AOF 來恢復數(shù)據(jù)。

缺點：

• 對于具有相同數(shù)據(jù)的的 Redis，AOF 文件通常會比 RDF 文件體積更大

• 在 Redis 的負載較高時，RDB 比 AOF 具好更好的性能保證

• AOF可能存在bug

“什么是Redis持久化”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質量的實用文章！

新聞名稱：什么是Redis持久化
URL標題：http://www.chinadenli.net/article24/gpcpje.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供微信公眾號、品牌網(wǎng)站制作、電子商務、建站公司、外貿建站、網(wǎng)站設計公司

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)