一、持久化的作用
1.什么是持久化
redis的所有數(shù)據(jù)保存在內(nèi)存中，對數(shù)據(jù)的更新將異步的保存到硬盤上
2.持久化的實現(xiàn)方式
快照：某時某刻數(shù)據(jù)的一個完成備份 -mysql的Dump -redis的RDB寫日志：任何操作記錄日志，要恢復數(shù)據(jù)，只要把日志重新走一遍即可 -mysql的 Binlog -Hhase的 HLog -Redis的 AOF
二、RDB
1.什么是RDB
2.觸發(fā)機制-主要三種方式
第一種：save(同步)
1 客戶端輸入save命令----》redis服務(wù)端----》同步創(chuàng)建RDB二進制文件
2 會造成redis的阻塞（數(shù)據(jù)量非常大的時候）
3 文件策略：如果老的RDB存在，會替換老的
4 復雜度 o(n)
第二種：bgsave(異步，Backgroud saving started)
1 客戶端輸入save命令----》redis服務(wù)端----》異步創(chuàng)建RDB二進制文件（fork函數(shù)生成一個子進程（fork會阻塞reids），執(zhí)行createRDB，執(zhí)行成功，返回給reids消息）
2 此時訪問redis，會正常響應客戶端
3 文件策略：跟save相同，如果老的RDB存在，會替換老的
4 復雜度 o(n)
第三種：(常用方式)（******）自動（通過配置文件）
配置 seconds changes
save 900 1save 300 10save 60 10000如果60s中改變了1w條數(shù)據(jù)，自動生成rdb
如果300s中改變了10條數(shù)據(jù)，自動生成rdb
如果900s中改變了1條數(shù)據(jù)，自動生成rdb
以上三條符合任意一條，就自動生成rdb，內(nèi)部使用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出現(xiàn)錯誤，是否停止寫入，默認為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
#出現(xiàn)錯誤停止
rdbcompression yes #壓縮
rdbchecksum yes #校驗
RDB觸發(fā)機制一般使用第三種方式，但是這種方式也會有缺點。如果修改的條數(shù)沒有在設(shè)置范圍內(nèi)那么就不會觸發(fā)，就會引發(fā)很多數(shù)據(jù)沒有持久化的情況。所以我們一般采用下面方式：AOF。
如果是保存不重要的數(shù)據(jù)可以使用RDB方式（比如緩存數(shù)據(jù)），如果是保存很重要的數(shù)據(jù)就要使用AOF，但是兩種方式也可以同時使用。
三、AOF
1.RDB問題
耗時，耗性能。不可控，可能會丟失數(shù)據(jù)。
2.AOF介紹
客戶端每寫入一條命令，都記錄一條日志，放到日志文件中，如果出現(xiàn)宕機，可以將數(shù)據(jù)完全恢復
3.AOF的三種策略
日志不是直接寫到硬盤上，而是先放在緩沖區(qū)，緩沖區(qū)根據(jù)一些策略，寫到硬盤上
#第一種：always：redis--》寫命令刷新的緩沖區(qū)---》每條命令fsync到硬盤---》AOF文件
#第二種：everysec（默認值）：redis——》寫命令刷新的緩沖區(qū)---》每秒把緩沖區(qū)fsync到硬盤--》AOF文件
#第三種：no:redis——》寫命令刷新的緩沖區(qū)---》操作系統(tǒng)決定，緩沖區(qū)fsync到硬盤--》AOF文件
| 命令 | always | everysec | no |
| 優(yōu)點 | 不丟失數(shù)據(jù) | 每秒一次fsync，丟失1秒數(shù)據(jù) | 不用管 |
| 缺點 | IO開銷大，一般的sata盤只有幾百TPS | 丟1秒數(shù)據(jù) | 不可控 |
4.AOF重寫
隨著命令的逐步寫入，并發(fā)量的變大， AOF文件會越來越大，通過AOF重寫來解決該問題
| 原生AOF | AOF重寫 |
set hello world set hello java set hello hehe incr counter ncr counter rpush mylist a rpush mylist b rpush mylist c 過期數(shù)據(jù) | set hello hehe set counter 2 rpush mylist a b c |
本質(zhì)就是把過期的，無用的，重復的，可以優(yōu)化的命令，來優(yōu)化這樣可以減少磁盤占用量，加速恢復速度
實現(xiàn)方式
bgrewriteaof：客戶端向服務(wù)端發(fā)送bgrewriteaof命令，服務(wù)端會起一個fork進程，完成AOF重寫
AOF重寫配置：
重寫流程
AOF配置文件 （******）
appendonly yes #將該選項設(shè)置為yes，打開appendfilename "appendonly-${port}.aof" #文件保存的名字appendfsync everysec #采用第二種策略dir /bigdiskpath #存放的路徑no-appendfsync-on-rewrite yes #在aof重寫的時候，是否要做aof的append操作，因為aof重寫消耗性能，磁盤消耗，正常aof寫磁盤有一定的沖突，這段期間的數(shù)據(jù)，允許丟失
四、RDB和AOF的選擇
1.rdb和aof的比較
| 命令 | rdb | aof |
| 啟動優(yōu)先級 | 低 | 高(掛掉重啟，會加載aof的數(shù)據(jù)) |
| 體積 | 小 | 大 |
| 恢復速度 | 快 | 慢 |
| 數(shù)據(jù)安全性 | 丟數(shù)據(jù) | 根據(jù)策略決定 |
| 輕重 | 重 | 輕 |
2.rdb最佳策略
rdb關(guān)掉，主從操作時
集中管理：按天，按小時備份數(shù)據(jù)
主從配置，從節(jié)點打開
3.aof最佳策略
開：緩存和存儲，大部分情況都打開，
aof重寫集中管理
everysec：通過每秒刷新的策略
4.最佳策略
小分片：每個redis的大內(nèi)存為4g
緩存或存儲：根據(jù)特性，使用不通策略
時時監(jiān)控硬盤，內(nèi)存，負載網(wǎng)絡(luò)等
有足夠內(nèi)存
以上就是Redis如何實現(xiàn)持久化方案（RDB和AOF使用）的詳細內(nèi)容，更多請關(guān)注創(chuàng)新互聯(lián)成都網(wǎng)站設(shè)計公司其它相關(guān)文章！
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。
重慶分公司
重慶分公司
