一、為什么需要持久化
redis本身運行時數(shù)據(jù)保存在內(nèi)存中，如果不進行持久化，那么在redis出現(xiàn)非正常原因宕機或者關(guān)閉redis的進程或者關(guān)閉計算機后數(shù)據(jù)肯定被會操作系統(tǒng)從內(nèi)存中清掉。當(dāng)然，redis本身默認(rèn)采用了一種持久化方式，即RDB （Redis DataBase），可以在redis的目錄中找到dump.rdb文件，這就是使用RDB方式做持久化后生成的數(shù)據(jù)文件。
二、常見的兩種持久化方式
一、RDB(Redis Database)快照
1、是什么：即redis數(shù)據(jù)庫，rdb持久性以指定的時間間隔執(zhí)行數(shù)據(jù)集的時間點快照。
?2、作用：
在指定的時間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫入磁盤。也就是Snapshot內(nèi)存快照。等redis回復(fù)時再將硬盤快照文件直接讀回到內(nèi)存里。保存?zhèn)浞輹r執(zhí)行的是全量快照，把內(nèi)存中的所有數(shù)據(jù)都保存到dump.rdb文件
3、持久化觸發(fā)類型：
自動觸發(fā)：
手動觸發(fā)：
Redis提供了兩個命令來手動生成RDB文件
save：在主進程中執(zhí)行會阻塞當(dāng)前redis服務(wù)器，直到持久化工作完成，在執(zhí)行save命令期間，redis不能處理其他命令，線上禁止使用。
bgsave：redis會在后臺異步進行快照操作，不阻塞快照同時還可以響應(yīng)客戶端請求，該觸發(fā)方式會fork一個子進程由子進程復(fù)制持久化過程。
注意：生產(chǎn)上只允許用bgsave，不允許用save
lastsave：獲取最后一次成功執(zhí)行快照的時間，獲取到的是時間戳，在Linux中可以使用date -d @時間戳進行時間的轉(zhuǎn)換
4、如何恢復(fù)
將備份文件移動到redis安裝目錄并啟動服務(wù)即可。
注意：1、執(zhí)行flushall/flushdb命令也會產(chǎn)生dump.rdb文件，但里面是空的，沒有任何意義。2、物理恢復(fù)，服務(wù)和備份分機隔離。以防止生產(chǎn)機物理損壞后備份文件也掛了。
5、優(yōu)劣勢
優(yōu)點：官網(wǎng)
1、適合大規(guī)模數(shù)據(jù)恢復(fù)
2、按照業(yè)務(wù)定時備份
3、對數(shù)據(jù)完整性和一致性要求不高
4、RDB文件在內(nèi)存中的加載速度要比AOF快得多
缺點：官網(wǎng)
?1、在一定間隔時間做一次備份，如果redis意外宕機了，就會丟失從當(dāng)前至最近一次快照期間的數(shù)據(jù)，快照之間的數(shù)據(jù)會丟失。
2、內(nèi)存數(shù)據(jù)的全量同步，如果數(shù)據(jù)量太大會導(dǎo)致I/O嚴(yán)重影響服務(wù)器性能
3、RDB依賴于主進程的fork，在更大的數(shù)據(jù)集中，這可能導(dǎo)致服務(wù)請求的瞬間延遲。fork的時候內(nèi)存數(shù)據(jù)被克隆了一份，大致兩倍的膨脹，需要慎重考慮。
6、使用redis -check -rdb 對損壞的rdb文件進行修復(fù)
7、RDB的觸發(fā)
1、配置文件中默認(rèn)的快照配置，即多少時間內(nèi)進行了多少次redis數(shù)據(jù)的操作觸發(fā)rdb持久化機制
2、手動save/bgsave命令
3、執(zhí)行flashall/flashdb命令也會產(chǎn)生dump.rdb文件，但里面是空的，無意義。
4、執(zhí)行shutdown且沒有設(shè)置開啟aof持久化
5、主從復(fù)制時，主節(jié)點自動觸發(fā)
8、禁用rdb
1、redis-cli config set save ""：動態(tài)的所有停止rdb保存規(guī)則
2、配置文件上禁用
二、AOF(Append Only File)
一、是什么
?二、能干什么
主要是記錄每次redis的除讀取操作外的所有操作指令，AOF保存的是appendonly.aof文件
三、AOF持久化工作流程
四、AOF緩沖區(qū)三種寫回策略?
1、Always：同步寫回，每個寫命令執(zhí)行完立刻同步地將日志寫回磁盤。
2、everysec（默認(rèn)寫回策略）：每秒寫回，每個寫命令執(zhí)行完，只是先把日志寫到aof文件的內(nèi)存緩沖區(qū)，每隔1秒把緩沖區(qū)中的內(nèi)容寫入到磁盤文件。
3、no：操作系統(tǒng)控制的寫回。每個命令執(zhí)行完，只是先把日志寫到AOF文件的內(nèi)存緩沖區(qū)，由操作系統(tǒng)決定何時將緩沖區(qū)內(nèi)容寫回磁盤
五、redis7 Multi Part AOF 的設(shè)計?
redis7之前AOF文件有且只有一個 ，redis7之后有三個文件：base基本文件、incr增量文件、manifest清單文件，且有一個配置目錄用于和rdb區(qū)分
六、AOF異常文件修復(fù)
七、優(yōu)劣勢?
優(yōu)勢：?
劣勢：
1、對于相同數(shù)據(jù)集的數(shù)據(jù)而言AOF文件要大于RDB文件，且恢復(fù)速度要慢于RDB
2、AOF運行效率慢于RDB，每秒同步策略效率較好，不同步效率和RDB相同
八、AOF重寫機制?
?1、是什么
?啟動AOF文件的內(nèi)容壓縮，只保留可以恢復(fù)數(shù)據(jù)的最小指令集
2、兩種觸發(fā)機制?
自動觸發(fā)：
手動觸發(fā)： 直接發(fā)送bgrewriteaof命令?
重寫原理：
自Redis 7.0.0以來，當(dāng)安排AOF重寫時，Redis父進程會打開一個新的增量AOF文件以繼續(xù)寫入。子進程執(zhí)行重寫邏輯并生成新的基本AOF。Redis將使用一個臨時清單文件來跟蹤新生成的基本文件和增量文件。當(dāng)它們準(zhǔn)備好后，Redis將執(zhí)行原子替換操作，使這個臨時清單文件生效。為了避免在AOF重寫重復(fù)失敗和重試的情況下創(chuàng)建許多增量文件的問題，Redis引入了AOF重寫限制機制，以確保失敗的AOF重寫以越來越慢的速度重試。?
Redis會fork一個子進程，所以現(xiàn)在我們有了一個子進程和一個父進程。
子級開始在臨時文件中寫入新的基本AOF。
父級打開一個新的增量AOF文件以繼續(xù)寫入更新。如果重寫失敗，舊的基本文件和增量文件（如果有的話）加上這個新打開的增量文件代表了完整的更新數(shù)據(jù)集，所以我們是安全的。
當(dāng)子級完成重寫基本文件時，父級會得到一個信號，并使用新打開的增量文件和子級生成的基本文件來構(gòu)建臨時清單，并將其持久化。
利潤現(xiàn)在Redis對清單文件進行原子交換，以便AOF重寫的結(jié)果生效。Redis還會清理舊的基本文件和任何未使用的增量文件。
總結(jié)：
?
?三、AOF+RDB混合使用
一、同時開啟兩種持久化方式
reds默認(rèn)是開啟RDB持久化，而不會開啟AOF持久化方式，如果兩者同時開啟，redis優(yōu)先加載AOF持久化。
?二、redis加載順序
當(dāng)redis重啟的時候會優(yōu)先加載AOF文件來恢復(fù)原始的數(shù)據(jù)，因為通常情況下AOF文件保存的數(shù)據(jù)集要比RDB文件保存的數(shù)據(jù)集更完整。RDB的數(shù)據(jù)不實時，同時使用兩者時服務(wù)器重啟也只會找AOF文件。由于RDB更適合用于備份數(shù)據(jù)庫(AOF在不斷變化不好備份)，留著RDB作為一個兜底策略。
?
?
四、純緩存模式
redis并不做持久化，只用做高速緩存，禁用持久化機制可以提高性能。
1、關(guān)閉RDB：save ""；禁用RDB自動觸發(fā)模式，手動觸發(fā)還是可以的
2、關(guān)閉AOF：appendonly no；禁用AOF寫回策略，手動觸發(fā)還是可以的。
?文章來源地址http://www.zghlxwxcb.cn/news/detail-449098.html文章來源：http://www.zghlxwxcb.cn/news/detail-449098.html
?
到了這里，關(guān)于Redis系列--redis持久化的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
