這篇文章給大家分享的是有關(guān)Redis持久化是什么意思的內(nèi)容。小編覺得挺實用的，因此分享給大家做個參考。一起跟隨小編過來看看吧。

成都創(chuàng)新互聯(lián)公司從2013年成立，公司以成都做網(wǎng)站、成都網(wǎng)站建設(shè)、成都外貿(mào)網(wǎng)站建設(shè)、系統(tǒng)開發(fā)、網(wǎng)絡(luò)推廣、文化傳媒、企業(yè)宣傳、平面廣告設(shè)計等為主要業(yè)務(wù)，適用行業(yè)近百種。服務(wù)企業(yè)客戶成百上千，涉及國內(nèi)多個省份客戶。擁有多年網(wǎng)站建設(shè)開發(fā)經(jīng)驗。為企業(yè)提供專業(yè)的網(wǎng)站建設(shè)、創(chuàng)意設(shè)計、宣傳推廣等服務(wù)。 通過專業(yè)的設(shè)計、獨特的風(fēng)格，為不同客戶提供各種風(fēng)格的特色服務(wù)。

演示環(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ù)的工作機制稱為持久化。

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

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

第二種操作過程，存儲操作過程，存儲結(jié)構(gòu)復(fù)雜，關(guā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文件格式校驗，該校驗過程在寫文件和讀文件過程均進(jìn)行

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

其實這個數(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 -- 配置文件自啟動

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í)行AOF文件中命令達(dá)到數(shù)據(jù)恢復(fù)的目的。與RDB相比可以簡單描述為記錄數(shù)據(jù)產(chǎn)生的過程

AOF的主要作用是解決了數(shù)據(jù)持久化的實時性，目前已經(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)突然宕機的情況下回丟失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重寫機制壓縮文件體積。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ā)者成運維人手工維護(hù)的），且恢復(fù)速度較快，階段點數(shù)據(jù)恢復(fù)通常采用RDB方案
  • 注 意 ： 利 用RDB實現(xiàn)緊促的數(shù)據(jù)持久化會使Redis降的很低

• 綜合對比

  • RDB與AOF的選擇實際上是在做一種權(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ù)的量

感謝各位的閱讀！關(guān)于Redis持久化是什么意思就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，讓大家可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！

網(wǎng)站欄目：Redis持久化是什么意思-創(chuàng)新互聯(lián)
分享鏈接：http://weahome.cn/article/gcjsh.html