演示環(huán)境

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

1. 持久化簡(jiǎn)介

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

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

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

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

2. RDB

2-1 RDB啟動(dòng)方式  --  save命令

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

2-2 RDB啟動(dòng)方式  --  save指令相關(guān)配置

• dbfilename dump6379.rdb ：設(shè)置本地?cái)?shù)據(jù)庫(kù)文件名，默認(rèn)值為dump.rdb
• dir：存儲(chǔ)rdb文件的路徑
• rdbcompression yes ：設(shè)置存儲(chǔ)至本地?cái)?shù)據(jù)庫(kù)時(shí)是否壓縮數(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í)這個(gè)數(shù)據(jù)恢復(fù)相對(duì)于其他關(guān)系型數(shù)據(jù)庫(kù)恢復(fù)基本就不用操作什么。只需要重新在啟動(dòng)就好了

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

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

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

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

這個(gè)時(shí)候我們?cè)诳匆幌氯罩疚募?，bgsave命令是針對(duì)save阻塞問題做的優(yōu)化

2-5 RDB -- 配置文件自啟動(dòng)

save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes

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

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

3. AOF

3-1 AOF概念

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

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

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

執(zhí)行一條redis命令

redis的AOF會(huì)把命令刷新緩沖區(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文件了然后我們?cè)趓edis客戶端執(zhí)行一條命令，在來查看一下?？梢钥吹綌?shù)據(jù)都會(huì)存入appendonly.aof這個(gè)文件中。

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

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

3-6 AOF重寫

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

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

3-7 AOF重寫作用

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

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

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

3-9 AOF手動(dòng)重寫

指令：bgrewriteaof

接著我們3-5的問題，我們?cè)诿钚袌?zhí)行bgrewriteaof指令然后查看appendonly.aof文件

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

3-10 AOF手動(dòng)重寫工作原理

3-11 AOF自動(dòng)重寫

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

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

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

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

4. RDB和AOF區(qū)別

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

  • AOF持久化策略使用everysecond, 每 秒 鐘fsync-次?該策略redis仍可以保持很好的處理性能，當(dāng)出現(xiàn)問題時(shí)， 最 多丟失0-1秒內(nèi)的數(shù)據(jù).
  • 注意：由于AO文件存儲(chǔ)體積較大，且恢復(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ù)持久化會(huì)使Redis降的很低

• 綜合對(duì)比

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