RBD（Redis DateBase）

1. 自動(dòng)備份：在指定的時(shí)間間隔內(nèi)把數(shù)據(jù)快照寫(xiě)進(jìn)磁盤
2. 手動(dòng)備份：
   save：阻塞其他所有的任務(wù)
   bgsave：后臺(tái)進(jìn)行save
3. 手動(dòng)停止RDB保存規(guī)則方法：redis-cli config set save ""

redis-check-dump --fix filename.rdb：修復(fù)rdb文件

備份策略：

在一定的時(shí)間間隔內(nèi)，如果修改的記錄數(shù)超過(guò)某個(gè)值，就進(jìn)行備份。默認(rèn)是900秒內(nèi)修改一條，300秒內(nèi)修改10條或者60秒內(nèi)修改10000條

RBD其他自動(dòng)觸發(fā)機(jī)制

1. 在主從復(fù)制場(chǎng)景下，如果從節(jié)點(diǎn)執(zhí)行全量復(fù)制操作，則主節(jié)點(diǎn)會(huì)執(zhí)行bgsave命令，并將rdb文件發(fā)送給從節(jié)點(diǎn)
2. 執(zhí)行shutdown命令時(shí)，自動(dòng)執(zhí)行rdb持久化

備份策略原理

Redis的save m n，是通過(guò)serverCron函數(shù)、dirty計(jì)數(shù)器、和lastsave時(shí)間戳來(lái)實(shí)現(xiàn)的。

serverCron是Redis服務(wù)器的周期性操作函數(shù)，默認(rèn)每隔100ms執(zhí)行一次；該函數(shù)對(duì)服務(wù)器的狀態(tài)進(jìn)行維護(hù)，其中一項(xiàng)工作就是檢查 save m n 配置的條件是否滿足，如果滿足就執(zhí)行bgsave。

dirty計(jì)數(shù)器是Redis服務(wù)器維持的一個(gè)狀態(tài)，記錄了上一次執(zhí)行bgsave/save命令后，服務(wù)器狀態(tài)進(jìn)行了多少次修改(包括增刪改)；而當(dāng)save/bgsave執(zhí)行完成后，會(huì)將dirty重新置為0。

例如，如果Redis執(zhí)行了set mykey helloworld，則dirty值會(huì)+1；如果執(zhí)行了sadd myset v1 v2 v3，則dirty值會(huì)+3；注意dirty記錄的是服務(wù)器進(jìn)行了多少次修改，而不是客戶端執(zhí)行了多少修改數(shù)據(jù)的命令。

lastsave時(shí)間戳也是Redis服務(wù)器維持的一個(gè)狀態(tài)，記錄的是上一次成功執(zhí)行save/bgsave的時(shí)間。

save m n的原理如下：每隔100ms，執(zhí)行serverCron函數(shù)；在serverCron函數(shù)中，遍歷save m n配置的保存條件，只要有一個(gè)條件滿足，就進(jìn)行bgsave。對(duì)于每一個(gè)save m n條件，只有下面兩條同時(shí)滿足時(shí)才算滿足：

1. 當(dāng)前時(shí)間-lastsave > m
2. dirty >= n

壓縮：LZF壓縮，會(huì)損耗一定的CPU性能，默認(rèn)開(kāi)啟，建議開(kāi)啟
校驗(yàn)：CRC64校驗(yàn)，會(huì)損耗一定的CPU性能，默認(rèn)開(kāi)啟，建議開(kāi)啟。

執(zhí)行flushall會(huì)刪除掉所有的記錄，該情況滿足自動(dòng)備份條件，會(huì)立刻進(jìn)行備份，但是備份的rdb文件為空

RBD缺點(diǎn)：

1. 每隔一定時(shí)間進(jìn)行一次保存，如果redis意外宕機(jī)，則會(huì)丟失最后一次snapshot
2. 備份時(shí)需要fork一份當(dāng)前的數(shù)據(jù)，需要額外的空閑空間，還會(huì)導(dǎo)致在一些毫秒級(jí)不能相應(yīng)客戶端請(qǐng)求

RBD優(yōu)點(diǎn)

1. RDB是一個(gè)非常緊湊的文件
2. 備份時(shí)，只需要主進(jìn)程fork一個(gè)子進(jìn)程，接下來(lái)的任務(wù)都由子進(jìn)程完成，可以最大化redis性能
3. 與AOF相比，恢復(fù)大數(shù)據(jù)集的時(shí)候會(huì)更快一些。

AOF（Append only File）

記錄Redis執(zhí)行過(guò)的所有寫(xiě)操作，redis啟動(dòng)的時(shí)候會(huì)把a(bǔ)of文件中的所有命令從前到后執(zhí)行一次，只允許追加文件。默認(rèn)不使用

redis-cli appendonly.aof：使用aof文件進(jìn)行恢復(fù)
redis-check-aof --fix filename.aof：修復(fù)aof文件命令。刪除filename.aof文件中所有不符合aof語(yǔ)法的句子

備份策略

實(shí)時(shí)（always）：保存每一條寫(xiě)命令，對(duì)性能要求高，不會(huì)有數(shù)據(jù)丟失。
每秒（everysec）：每秒保存一次寫(xiě)命令，如果redis服務(wù)器宕機(jī)，會(huì)有數(shù)據(jù)丟失。默認(rèn)采取每秒（everysec）
不追加（no）：不保存寫(xiě)命令

重寫(xiě)

當(dāng)AOF文件越來(lái)越大到一定閾值的時(shí)候，redis會(huì)采取重寫(xiě)策略，將內(nèi)容壓縮。
AOF rewrite操作就是“壓縮”AOF文件的過(guò)程，當(dāng)然redis并沒(méi)有采用“基于原aof文件”來(lái)重寫(xiě)的方式，而是采取了類似snapshot的方式：基于copy-on-write，全量遍歷內(nèi)存中數(shù)據(jù)，然后逐個(gè)序列到aof文件中。因此AOF rewrite能夠正確反應(yīng)當(dāng)前內(nèi)存數(shù)據(jù)的狀態(tài)，這正是我們所需要的；
rewrite過(guò)程中，新的變更操作將仍然被寫(xiě)入到原AOF文件中，同時(shí)這些新的變更操作也會(huì)被redis收集起來(lái)(buffer，copy-on-write方式下，最極端的可能是所有的key都在此期間被修改，將會(huì)耗費(fèi)2倍內(nèi)存)，當(dāng)內(nèi)存數(shù)據(jù)被全部寫(xiě)入到新的aof文件之后，原aof文件中收集的新的變更操作也將會(huì)一并追加到新的aof文件中，然后把新的aof文件重命名為appendonly.aof,此后所有的操作都將被寫(xiě)入新的aof文件。
如果在rewrite過(guò)程中出現(xiàn)故障，將不會(huì)影響原AOF文件的正常工作，只有當(dāng)rewrite完成之后才會(huì)切換文件，因此rewrite過(guò)程是比較可靠的。

AOF缺點(diǎn)**

1. 恢復(fù)相同大小的數(shù)據(jù)，AOF文件遠(yuǎn)大于RDB，運(yùn)行效率也低于RBD
2. aof文件rewrite操作，把數(shù)據(jù)壓縮寫(xiě)到新的文件中的時(shí)候會(huì)導(dǎo)致幾乎無(wú)法避免的阻塞。

AOF優(yōu)點(diǎn)

1. aof文件可讀性好
2. 數(shù)據(jù)完整新好，最壞只會(huì)丟失2s的數(shù)據(jù)

RBD和AOF

• redis啟動(dòng)的時(shí)候自動(dòng)從rbd或aof文件中恢復(fù)數(shù)據(jù)。
• RBD和AOF兩種恢復(fù)機(jī)制可以共存。兩者共存時(shí)，redis啟動(dòng)時(shí)優(yōu)先使用AOF恢復(fù)數(shù)據(jù)，如果AOF文件中出現(xiàn)錯(cuò)誤，則無(wú)法啟動(dòng)redis
• RBD只作后備用途，建議在Slave上使用RDB策略，且只需要15分鐘保存一次。
• 啟用AOF，好處是最壞情況下也只損失2秒的數(shù)據(jù)。但是會(huì)帶來(lái)新的問(wèn)題
  1. aof文件rewrite操作，把數(shù)據(jù)壓縮寫(xiě)入新的文件中的時(shí)候會(huì)導(dǎo)致幾乎無(wú)法避免的阻塞。
  2. 導(dǎo)致持續(xù)的IO
• 如果不用AOF，只在主從模式下啟用RBD，也可以實(shí)現(xiàn)高可用。只是當(dāng)主從服務(wù)器同時(shí)掛掉的時(shí)候會(huì)損失15分鐘的數(shù)據(jù)，而且恢復(fù)數(shù)據(jù)時(shí)需要比較主從服務(wù)器上的數(shù)據(jù)，選擇其中較新的來(lái)恢復(fù)