Redis(四)——持久化方案（RDB和AOF使用）

一、持久化的作用

1.什么是持久化

redis的所有數據保存在內存中，對數據的更新將異步的保存到硬盤上

2.持久化的實現方式

快照：某時某刻數據的一個完成備份 -mysql的Dump
    -redis的RDB
寫日志：任何操作記錄日志，要恢復數據，只要把日志重新走一遍即可 -mysql的 Binlog
    -Hhase的 HLog
    -Redis的 AOF

二、RDB

1.什么是RDB

 

 

2.觸發機制-主要三種方式

第一種：
save(同步) 1 客戶端輸入save命令----》redis服務端----》同步創建RDB二進制文件 2 會造成redis的阻塞（數據量非常大的時候） 3 文件策略：如果老的RDB存在，會替換老的 4 復雜度 o(n)

第二種：
bgsave(異步，Backgroud saving started) 1 客戶端輸入save命令----》redis服務端----》異步創建RDB二進制文件（fork函數生成一個子進程（fork會阻塞reids），執行createRDB，執行成功，返回給reids消息） 2 此時訪問redis，會正常響應客戶端 3 文件策略：跟save相同，如果老的RDB存在，會替換老的 4 復雜度 o(n) 
第三種：(常用方式)（******）
自動（通過配置文件） 配置 seconds changes save 900 1 save 300 10 save 60 10000 如果60s中改變了1w條數據，自動生成rdb 如果300s中改變了10條數據，自動生成rdb 如果900s中改變了1條數據，自動生成rdb 以上三條符合任意一條，就自動生成rdb，內部使用bgsave

#配置：
save 900 1 #配置一條
save 300 10 #配置一條
save 60 10000 #配置一條
dbfilename dump.rdb  #rdb文件的名字，默認為dump.rdb
dir ./ #rdb文件存在當前目錄

stop-writes-on-bgsave-error yes #如果bgsave出現錯誤，是否停止寫入，默認為yes
rdbcompression yes #采用壓縮格式
rdbchecksum yes #是否對rdb文件進行校驗和檢驗

#最佳配置
save 900 1 
save 300 10 
save 60 10000 
dbfilename dump-${port}.rdb  #以端口號作為文件名，可能一台機器上很多reids，不會亂
dir /bigdiskpath #保存路徑放到一個大硬盤位置目錄
stop-writes-on-bgsave-error yes #出現錯誤停止
rdbcompression yes #壓縮
rdbchecksum yes #校驗

RDB觸發機制一般使用第三種方式，但是這種方式也會有缺點。如果修改的條數沒有在設置范圍內那么就不會觸發，就會引發很多數據沒有持久化的情況。所以我們一般采用下面方式：AOF。

如果是保存不重要的數據可以使用RDB方式（比如緩存數據），如果是保存很重要的數據就要使用AOF，但是兩種方式也可以同時使用。

三、AOF

1.RDB問題

耗時，耗性能。不可控，可能會丟失數據。

2.AOF介紹

客戶端每寫入一條命令，都記錄一條日志，放到日志文件中，如果出現宕機，可以將數據完全恢復

3.AOF的三種策略

日志不是直接寫到硬盤上，而是先放在緩沖區，緩沖區根據一些策略，寫到硬盤上
#第一種：
always：redis--》寫命令刷新的緩沖區---》每條命令fsync到硬盤---》AOF文件
#第二種：
everysec（默認值）：redis——》寫命令刷新的緩沖區---》每秒把緩沖區fsync到硬盤--》AOF文件
#第三種：
no:redis——》寫命令刷新的緩沖區---》操作系統決定，緩沖區fsync到硬盤--》AOF文件

命令	always	everysec	no
優點	不丟失數據	每秒一次fsync，丟失1秒數據	不用管
缺點	IO開銷大，一般的sata盤只有幾百TPS	丟1秒數據	不可控

4.AOF重寫

隨着命令的逐步寫入，並發量的變大， AOF文件會越來越大，通過AOF重寫來解決該問題

原生AOF	AOF重寫
set hello world<br/> set hello java<br/> set hello hehe<br/> incr counter<br/> ncr counter<br/> rpush mylist a<br/> rpush mylist b<br/> rpush mylist c<br/> 過期數據	set hello hehe<br/> set counter 2<br/> rpush mylist a b c

本質就是把過期的，無用的，重復的，可以優化的命令，來優化這樣可以減少磁盤占用量，加速恢復速度

實現方式

bgrewriteaof：

客戶端向服務端發送bgrewriteaof命令，服務端會起一個fork進程，完成AOF重寫

AOF重寫配置：

配置名	含義
auto-aof-rewrite-min-size	AOF文件重寫需要尺寸
auto-aof-rewrite-percentage	AOF文件增長率

統計名	含義
aof_current_size	AOF當前尺寸（單位：字節）
aof_base_size	AOF上次啟動和重寫的尺寸（單位：字節）

自動觸發時機（兩個條件同時滿足）：

aof_current_size>auto-aof-rewrite-min-size：當前尺寸大於重寫需要尺寸

(aof_current_size-aof_base_size)/aof_base_size>auto-aof-rewrite-percentage:（增長率）當前尺寸減去上次重寫的尺寸，除以上次重寫的尺寸如果大於配置中的增長率

重寫流程

 

AOF配置文件 （******）

appendonly yes #將該選項設置為yes，打開
appendfilename "appendonly-${port}.aof" #文件保存的名字
appendfsync everysec #采用第二種策略
dir /bigdiskpath #存放的路徑
no-appendfsync-on-rewrite yes #在aof重寫的時候，是否要做aof的append操作，因為aof重寫消耗性能，磁盤消耗，正常aof寫磁盤有一定的沖突，這段期間的數據，允許丟失

四、RDB和AOF的選擇

1.rdb和aof的比較

命令	rdb	aof
啟動優先級	低	高(掛掉重啟，會加載aof的數據)
體積	小	大
恢復速度	快	慢
數據安全性	丟數據	根據策略決定
輕重	重	輕

2.rdb最佳策略

rdb關掉，主從操作時

集中管理：按天，按小時備份數據

主從配置，從節點打開

3.aof最佳策略

開：緩存和存儲，大部分情況都打開，

aof重寫集中管理

everysec：通過每秒刷新的策略

4.最佳策略

小分片：每個redis的最大內存為4g

緩存或存儲：根據特性，使用不通策略

時時監控硬盤，內存，負載網絡等

有足夠內存

 

。。。