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

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

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

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

Redis默認(rèn)是快照RDB的持久化方式

RDB

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

• 自動觸發(fā)

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

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

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

• 手動觸發(fā)

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

1. save

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

2. bgsave

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

基本上 Redis 內(nèi)部所有的RDB操作都是采用 bgsave 命令

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

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

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

RDB優(yōu)勢與劣勢

優(yōu)勢：

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

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

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

劣勢：

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

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

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

AOF

AOF配置

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

• appendonly no默認(rèn)配置，表示不開啟AOF持久化

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

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

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

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

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

AOF文件恢復(fù)

重啟 Redis 之后就會進(jìn)行 AOF 文件的載入

AOF重寫

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

舉個例子：

sadd key "A" "B" "C"

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

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

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

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

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

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

AOF優(yōu)缺點

優(yōu)點：

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

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

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

缺點：

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

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

• AOF可能存在bug

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