持久化的簡介

RDB

AOF

RDB與AOF的區(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ù)進程保存，在特定的時間將保存的數(shù)據(jù)進行恢復的工作機制稱為持久化。

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

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

第二種操作過程，存儲操作過程，關注點在數(shù)據(jù)的操作過程，也就是下文會講到的AOF

2. RDB

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

下圖是redis.conf的配置信息，在執(zhí)行完save后會生成一個dump.rdb的文件

現(xiàn)在我們設置一個值，然后save一下，在/usr/local/redis/data下就會有一個dump6379.rdb的一個文件

2-2 RDB使用方式之save

dbfilename dump6379.rdb ：設置RDB文件名，默認值為dump.rdb

dir：存儲rdb或者aof文件的路徑

rdbcompression yes ：設置存儲時是否壓縮數(shù)據(jù)，默認為yes，采用lzf壓縮

rdbchecksum yes：設置是否進行RDB文件格式校驗，該校驗過程在寫文件和讀文件過程均進行

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

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

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

當你執(zhí)行save時，其他客戶端請求redis的指令都會等待，直到save指令執(zhí)行完成。因為save指令是單線程執(zhí)行，一旦執(zhí)行時間過長會直接導致其他用戶端無法正常存儲數(shù)據(jù)。所以這個指令我們默認被廢棄。會使用下文介紹的bgsave來代替

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

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

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

2-5 RDB -- 配置文件自啟動

以下配置是默認配置

save 900 1

save 300 10

save 60 10000

stop-writes-on-bgsave-error yes

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

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

3. AOF

3-1 AOF概念

AOF文件存儲的是執(zhí)行命令操作過程，恢復數(shù)據(jù)也是使用操作過程來恢復。

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

執(zhí)行一條redis命令

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

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

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

always：執(zhí)行的命令都會存儲到AOF文件中，數(shù)據(jù)零誤差，性能較低，不建議使用

everysec：每秒將緩沖區(qū)中的指令同步到AOF文件中，數(shù)據(jù)準確性較高，性能較高，建議使用，也是默認配置。但是在系統(tǒng)突然宕機的情況下回丟失1秒內(nèi)的數(shù)據(jù)

no：由操作系統(tǒng)控制每次同步到AOF文件的周期，整體過程不可控

3-4 AOF功能開啟

配置：appendonly yes|no

作用：是否開啟AOF持久化功能，默認為不開啟狀態(tài)

配置：appendfsync always| everysec | no

作用：AOF寫數(shù)據(jù)策略

配置：appenfilename filename

作用：AOF持久化文件名，默認名為appendonly.aof

然后使用重啟redis服務，就可以在usr/local/redis/data目錄下可以看到appendonly.aof文件了

然后我們在redis客戶端執(zhí)行一條命令，在來查看一下。可以看到數(shù)據(jù)都會存入appendonly.aof這個文件中。

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

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

3-6 AOF重寫

如在上邊我們執(zhí)行了三次 set name 指令，但是我們最終就只需要最后一次執(zhí)行的記錄。也就是我們只需要最后一次執(zhí)行記錄即可。其他的記錄就不需要了，然后會把壓縮后的數(shù)據(jù)重寫到aof文件中。

重寫后我們的磁盤利用率就提高了

還有就是我們恢復數(shù)據(jù)的速度也會變快

同時也會提高持久化的效率

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

進程內(nèi)已超時的數(shù)據(jù)不再寫入文件

忽略刪除指令，如del，hdel，srem。 還有就是3-5說的問題，連續(xù)對一個key進行操作

對同一數(shù)據(jù)的多條寫入記錄合并為一條記錄：如lpush list a lpush lsit b lpush list c可以轉化為lpush list a b c。

3-8 AOF手動重寫

指令：bgrewriteaof

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

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

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

3-10 AOF自動重寫

配置：auto-aof-rewrite-percentage 100 | auto-aof-rewrite-min-size 64mb

觸發(fā)對比參數(shù)：aof_current_size | aof_base_size

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

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

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

4. 總結

以上就是redis持久化的所有內(nèi)容。

總結

以上是生活随笔為你收集整理的php使用redis持久化,Redis持久化完整版本的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。