一文帶你了解Redis持久化完整版本

❝

本文講解知識點 持久化的簡介 RDB AOF RDB與AOF的差別 持久化應用場景

❞

#前言

❝

喀喀爾整理了一個路線圖，打造一份面試寶典，準備按照這樣的路線圖進行寫文章，後期發現沒有補充到的知識點在進行添加。也期待各位夥伴一起來幫忙補充一下。評論區見！

❞

在這裡插入圖片描述

示範環境

centos7.0 redis4.0 redis存放目錄：/usr/local/redis redis.conf存放目錄：/usr/local/redis/data

1. 持久化簡介

#redis的所有資料都是保存在記憶體中，redis崩掉資料會遺失。 redis持久化就是把資料保存在磁碟上。利用永久性儲存媒體將資料進程保存，在特定的時間將保存的資料進行復原的工作機制稱為持久化。

持久化過程保存的是什麼呢？

第一種快照形式，儲存資料結果，關注點在數據，也就是下文會講到的RDB

第二種操作過程，儲存操作過程，儲存結構複雜，關注點在資料的操作過程，也就是下文會講到的AOF

2. RDB

2-1 RDB啟動方式 --  save指令

#下圖是redis.conf的設定訊息，執行完save後會產生一個dump.rdb的檔案現在我們設定一個值，然後save一下，在/usr/local/redis/data下就會有一個dump6379.rdb的一個檔案

2-2 RDB啟動方式 --  save指令相關設定

• ##dbfilename dump6379.rdb ：設定本機資料庫檔名，預設值為dump.rdb
• dir：儲存rdb檔案的路徑
• rdbcompression yes ：設定儲存至本機資料庫時是否壓縮數據，預設為yes，採用lzf壓縮
• rdbchecksum yes：設定是否進程RDB檔案格式校驗，該校驗過程在寫檔案和讀取檔案過程均進行

2-3 RDB資料復原

#其實這個資料復原相對於其他關係型資料庫復原基本上就不用操作什麼。只需要重新在啟動就好了

2-4 RDB -- save指令工作原理

此圖源自網路視訊。 save指令的執行會阻塞目前redis伺服器，直到目前RDB過程完為止，有可能會造成長時間的阻塞。這個指令在工作過程中基本上以被廢棄不在使用。會以bgsave全部代替

2-5 RDB -- bgsave指令運作原理

#當在redis執行了bgsave後會直接傳回一個Background saving started

這個時候我們在看日誌文件，bgsave指令是針對save阻塞問題做的最佳化

RDB -- 設定檔自啟動

<span style="display: block; background: url(https://my-wechat.mdnice.com/point.png); height: 30px; width: 100%; background-size: 40px; background-repeat: no-repeat; background-color: #272822; margin-bottom: -7px; border-radius: 5px; background-position: 10px 10px;"></span><code class="hljs" style="overflow-x: auto; padding: 16px; color: #ddd; display: -webkit-box; font-family: Operator Mono, Consolas, Monaco, Menlo, monospace; font-size: 12px; -webkit-overflow-scrolling: touch; letter-spacing: 0px; padding-top: 15px; background: #272822; border-radius: 5px;"><span class="hljs-selector-tag" style="color: #f92672; font-weight: bold; line-height: 26px;">save</span> 900 1<br/><span class="hljs-selector-tag" style="color: #f92672; font-weight: bold; line-height: 26px;">save</span> 300 10<br/><span class="hljs-selector-tag" style="color: #f92672; font-weight: bold; line-height: 26px;">save</span> 60 10000<br/><span class="hljs-selector-tag" style="color: #f92672; font-weight: bold; line-height: 26px;">stop-writes-on-bgsave-error</span> <span class="hljs-selector-tag" style="color: #f92672; font-weight: bold; line-height: 26px;">yes</span><br/></code>

save  【時間】 【key改變數量】

也就是說在300秒有10個key值改變了，就會在背景執行bgsave###

3. AOF

#3-1 AOF概念

AOF持久化：以獨立日誌的方式記錄每次寫入命令，重啟時在重新執行AOF檔案中命令達到資料復原的目的。與RDB相比可以簡單描述為記錄資料產生的過程

AOF的主要作用是解決了資料持久化的即時性，目前已經是redis持久化的主流方式

3-2 AOF寫入資料過程

#執行一個redis指令

redis的AOF會把指令刷新緩衝區

然後根據一定的策略同步的到redis.conf配置的.aof檔案中

3-3 AOF寫入資料的三種策略

• #always：每次寫入操作皆同步到AOF檔中，資料零誤差，效能較低，不建議使用
• everysec：每秒將緩衝區中的指令同步到AOF檔中，資料準確度較高，效能較高，建議使用，也是預設配置。但在系統突然宕機的情況下回遺失1秒內的資料
• no：由作業系統控制每次同步到AOF檔的週期，整體過程不可控

3-4 AOF功能開啟

• 設定： appendonly yes|no
• 作用：是否開啟AOF持久化功能，預設為不開啟狀態
• ##配置：
  appendfsync always| everysec | no
• 作用：AOF寫入資料策略
##設定：appenfilename filename
作用：AOF持久化檔名，預設為appendonly.aof

然後使用重新啟動redis服務，就可以在usr/local/redis/data目錄下可以看到appendonly.aof檔案了

然後我們在redis客戶端執行一條指令，在來查看一下。可以看到資料都會存入appendonly.aof這個檔案。

3-5 AOF寫入資料出現的問題

#我們先來看一個案例，我們重複設定了name這個key後，打開appendonly.aof檔案查看，可以看到有三個操作，但是這三個操作我們都是修改的一個key啊！我們只保存最後一個key不行嗎？帶著這個疑問，我們在繼續往下看

3-6 AOF重寫

隨著指令不斷寫入AOF，檔案會越來越大，為了解決這個問題，redis引入了AOF重寫機制壓縮檔案體積。 AOF檔案重寫是將redis進程內的資料轉換為寫入指令同步到新AOF檔的過程。簡單說就是將對同一個資料的若干條指令執行結果轉換為最終結果資料對應指令的執行記錄。

如在上邊我們執行了三次  set  name  指令，但是我們最後只需要最後一次執行的資料。也就是我們只需要最後一次執行記錄即可。

3-7 AOF重寫用

• #降低磁碟佔用量，提高磁碟利用率
• 提高持久化效率，降低持久化寫入時間，提高IO效能
• 降低資料復原用時，提高資料復原效率

3-8 AOF重寫規則

• #程式內已逾時的資料不再寫入檔案
• 忽略無效指令，重寫時使用進程內資料直接生成，這樣新的AOF檔值保留最終資料的寫入指令。如del指令，hdel，srem。多次設定一個key值等
• 對相同資料的多條寫入指令合併為一指令：如lpush list a lpush lsit b lpush list c可以轉化為lpush list a b c。但為了防止資料量過大造成客戶端緩衝區溢出，對list，set，hash，zset類型每條指令最多寫入64個元素

3-9 AOF手動重寫

#指令：bgrewriteaof

接著我們3- 5的問題，我們在命令列執行bgrewriteaof指令然後查看appendonly.aof檔案

當執行完後會發現檔案變小了，檔案裡也就只有一條指令了

在這裡插入圖片描述

#3-10 AOF手動重寫工作原理

在這裡插入圖片描述

3-11 AOF自動重寫

設定：auto-aof-rewrite-percentage 100 | auto-aof-rewrite-min-size 64mb觸發對比參數： aof_current_size | aof_base_size

當aof_current_size   >   auto-aof-rewrite-min-size 64mb  會啟動重寫

此圖來源於網絡

3-11 AOF工作流程和重写流=流程

4. RDB和AOF区别

• 对数据非常敏感，建议使用默认的AOF持久化方案

  • AOF持久化策略使用everysecond, 每 秒 钟fsync-次•该策略redis仍可以保持很好的处理性能，当出现问题时， 最 多丢失0-1秒内的数据.
  • 注意：由于AO文件存储体积较大，且恢复速度较慢

• 数据呈现阶段有效性，建议使用RDB持久化方案

  • 数据可以良好的做到阶段内无丟失（该阶段是开发者成运维人手工维护的），且恢复速度较快，阶段点数据恢复通常采用RDB方案
  • 注 意 ： 利 用RDB实现紧促的数据持久化会使Redis降的很低

• 综合对比

  • RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
  • 如不能承受数分钟以内的数据丢失，对业努数据非常敏感，选用A0F
  • 如能承受数分钟以内的数据丟失，旦追求大数据集的恢复速度，选用RDB
  • 灾难恢复使用RDB
  • 双保险策略，同时幵启RDB和AOF, 重启后，Redis优先使用A0F来恢复数据，降低丢失数据的量

  ❝

  坚持学习、坚持写博、坚持分享是咔咔从业以来一直所秉持的信念。希望在偌大互联网中咔咔的文章能带给你一丝丝帮助。我们下期再见。

  ❞

推荐：《redis教程》

以上是一文帶你了解Redis持久化完整版本的詳細內容。更多資訊請關注PHP中文網其他相關文章！