?

本文講解知識點(diǎn) 持久化的簡介 RDB AOF RDB與AOF的區(qū)別 持久化應(yīng)用場景

?

前言

?

咔咔整理了一個路線圖，打造一份面試寶典，準(zhǔn)備按照這樣的路線圖進(jìn)行編寫文章，后期發(fā)現(xiàn)沒有補(bǔ)充到的知識點(diǎn)在進(jìn)行添加。也期待各位伙伴一起來幫助補(bǔ)充一下。評論區(qū)見哦！

?

演示環(huán)境

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

1. 持久化簡介

redis的所有數(shù)據(jù)都是保存在內(nèi)存中，redis崩掉數(shù)據(jù)會丟失。redis持久化就是把數(shù)據(jù)保存在磁盤上。利用永久性存儲介質(zhì)將數(shù)據(jù)進(jìn)程保存，在特定的時間將保存的數(shù)據(jù)進(jìn)行恢復(fù)的工作機(jī)制稱為持久化。

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

第一種快照形式，存儲數(shù)據(jù)結(jié)果，關(guān)注點(diǎn)在數(shù)據(jù)，也就是下文會講到的RDB

第二種操作過程，存儲操作過程，存儲結(jié)構(gòu)復(fù)雜，關(guān)注點(diǎn)在數(shù)據(jù)的操作過程，也就是下文會講到的AOF

2. RDB

2-1 RDB啟動方式 ?— ?save命令

下圖是redis.conf的配置信息，在執(zhí)行完save后會生成一個dump.rdb的文件現(xiàn)在我們設(shè)置一個值，然后save一下，在/usr/local/redis/data下就會有一個dump6379.rdb的一個文件

2-2 RDB啟動方式 ?— ?save指令相關(guān)配置

• dbfilename dump6379.rdb ：設(shè)置本地數(shù)據(jù)庫文件名，默認(rèn)值為dump.rdb
• dir：存儲rdb文件的路徑
• rdbcompression yes ：設(shè)置存儲至本地數(shù)據(jù)庫時是否壓縮數(shù)據(jù)，默認(rèn)為yes，采用lzf壓縮
• rdbchecksum yes：設(shè)置是否進(jìn)程RDB文件格式校驗(yàn)，該校驗(yàn)過程在寫文件和讀文件過程均進(jìn)行

2-3 RDB數(shù)據(jù)恢復(fù)

其實(shí)這個數(shù)據(jù)恢復(fù)相對于其他關(guān)系型數(shù)據(jù)庫恢復(fù)基本就不用操作什么。只需要重新在啟動就好了

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

此圖來源于網(wǎng)絡(luò)視頻。 save指令的執(zhí)行會阻塞當(dāng)前redis服務(wù)器，直到當(dāng)前RDB過程完為止，有可能會造成長時間的阻塞。這個指令在工作過程中基本以被廢棄不在使用。會以bgsave全部代替

2-5 RDB — bgsave指令工作原理

當(dāng)在redis執(zhí)行了bgsave后會直接返回一個Background saving started

這個時候我們在看一下日志文件，bgsave命令是針對save阻塞問題做的優(yōu)化

2-5 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><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>

save ?【時間】 【key改變數(shù)量】

也就是說在300秒有10個key值發(fā)生變化了，就會在后臺執(zhí)行bgsave

3. AOF

3-1 AOF概念

AOF持久化：以獨(dú)立日志的方式記錄每次寫命令，重啟時在重新執(zhí)行AOF文件中命令達(dá)到數(shù)據(jù)恢復(fù)的目的。與RDB相比可以簡單描述為記錄數(shù)據(jù)產(chǎn)生的過程

AOF的主要作用是解決了數(shù)據(jù)持久化的實(shí)時性，目前已經(jīng)是redis持久化的主流方式

3-2 AOF寫數(shù)據(jù)過程

執(zhí)行一條redis命令

redis的AOF會把命令刷新緩沖區(qū)

然后根據(jù)一定的策略同步的到redis.conf配置的.aof文件中

3-3 AOF寫數(shù)據(jù)的三種策略

• always：每次寫入操作均同步到AOF文件中，數(shù)據(jù)零誤差，性能較低，不建議使用
• everysec：每秒將緩沖區(qū)中的指令同步到AOF文件中，數(shù)據(jù)準(zhǔn)確性較高，性能較高，建議使用，也是默認(rèn)配置。但是在系統(tǒng)突然宕機(jī)的情況下回丟失1秒內(nèi)的數(shù)據(jù)
• no：由操作系統(tǒng)控制每次同步到AOF文件的周期，整體過程不可控

3-4 AOF功能開啟

• 配置：appendonly yes|no
• 作用：是否開啟AOF持久化功能，默認(rèn)為不開啟狀態(tài)
• 配置：appendfsync always| everysec | no
• 作用：AOF寫數(shù)據(jù)策略
• 配置：appenfilename filename
• 作用：AOF持久化文件名，默認(rèn)名為appendonly.aof

然后使用重啟redis服務(wù)，就可以在usr/local/redis/data目錄下可以看到appendonly.aof文件了然后我們在redis客戶端執(zhí)行一條命令，在來查看一下。可以看到數(shù)據(jù)都會存入appendonly.aof這個文件中。

3-5 AOF寫數(shù)據(jù)出現(xiàn)的問題

我們先看一個案例，我們重復(fù)設(shè)置了name這個key后，打開appendonly.aof文件查看，可以看到有三個操作，但是這三個操作我們都是修改的一個key啊！我們只保存最后一個key不行嗎？帶著這個疑問，我們在繼續(xù)往下看

3-6 AOF重寫

隨著命令不斷寫入AOF，文件會越來越大，為了解決這個問題，redis引入了AOF重寫機(jī)制壓縮文件體積。AOF文件重寫是將redis進(jìn)程內(nèi)的數(shù)據(jù)轉(zhuǎn)化為寫命令同步到新AOF文件的過程。簡單說就是將對同一個數(shù)據(jù)的若干條命令執(zhí)行結(jié)果轉(zhuǎn)化為最終結(jié)果數(shù)據(jù)對應(yīng)指令的執(zhí)行記錄。

如在上邊我們執(zhí)行了三次 ?set ?name ?指令，但是我們最終就只需要最后一次執(zhí)行的數(shù)據(jù)。也就是我們只需要最后一次執(zhí)行記錄即可。

3-7 AOF重寫作用

• 降低磁盤占用量，提高磁盤利用率
• 提高持久化效率，降低持久化寫時間，提高IO性能
• 降低數(shù)據(jù)恢復(fù)用時，提高數(shù)據(jù)恢復(fù)效率

3-8 AOF重寫規(guī)則

• 進(jìn)程內(nèi)已超時的數(shù)據(jù)不再寫入文件
• 忽略無效指令，重寫時使用進(jìn)程內(nèi)數(shù)據(jù)直接生成，這樣新的AOF文件值保留最終數(shù)據(jù)的寫入命令。如del指令，hdel，srem。 ?多次設(shè)置一個key值等
• 對同一數(shù)據(jù)的多條寫入命令合并為一條命令：如lpush list a lpush lsit b lpush list c可以轉(zhuǎn)化為lpush list a b c。但是為了防止數(shù)據(jù)量過大造成客戶端緩沖區(qū)溢出，對list，set，hash，zset類型每條指令最多寫入64個元素

3-9 AOF手動重寫

指令：bgrewriteaof

接著我們3-5的問題，我們在命令行執(zhí)行bgrewriteaof指令然后查看appendonly.aof文件

當(dāng)執(zhí)行完后會發(fā)現(xiàn)文件變小了，文件里也就只有一條指令了

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

3-11 AOF自動重寫

配置：auto-aof-rewrite-percentage 100 | auto-aof-rewrite-min-size 64mb觸發(fā)對比參數(shù)：aof_current_size | aof_base_size

當(dāng)aof_current_size ? > ? auto-aof-rewrite-min-size 64mb ?會啟動重寫

此圖來源于網(wǎng)絡(luò)

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

4. RDB和AOF區(qū)別

• 對數(shù)據(jù)非常敏感，建議使用默認(rèn)的AOF持久化方案

  • AOF持久化策略使用everysecond, 每 秒 鐘fsync-次?該策略redis仍可以保持很好的處理性能，當(dāng)出現(xiàn)問題時， 最 多丟失0-1秒內(nèi)的數(shù)據(jù).
  • 注意：由于AO文件存儲體積較大，且恢復(fù)速度較慢

• 數(shù)據(jù)呈現(xiàn)階段有效性，建議使用RDB持久化方案

  • 數(shù)據(jù)可以良好的做到階段內(nèi)無丟失（該階段是開發(fā)者成運(yùn)維人手工維護(hù)的），且恢復(fù)速度較快，階段點(diǎn)數(shù)據(jù)恢復(fù)通常采用RDB方案
  • 注 意 ： 利 用RDB實(shí)現(xiàn)緊促的數(shù)據(jù)持久化會使Redis降的很低

• 綜合對比

  • RDB與AOF的選擇實(shí)際上是在做一種權(quán)衡，每種都有利有弊
  • 如不能承受數(shù)分鐘以內(nèi)的數(shù)據(jù)丟失，對業(yè)努數(shù)據(jù)非常敏感，選用A0F
  • 如能承受數(shù)分鐘以內(nèi)的數(shù)據(jù)丟失，旦追求大數(shù)據(jù)集的恢復(fù)速度，選用RDB
  • 災(zāi)難恢復(fù)使用RDB
  • 雙保險策略，同時幵啟RDB和AOF, 重啟后，Redis優(yōu)先使用A0F來恢復(fù)數(shù)據(jù)，降低丟失數(shù)據(jù)的量

  ?

  堅持學(xué)習(xí)、堅持寫博、堅持分享是咔咔從業(yè)以來一直所秉持的信念。希望在偌大互聯(lián)網(wǎng)中咔咔的文章能帶給你一絲絲幫助。我們下期再見。

  ?