Redis 持久化機制的意義
Redis 如果只是把數(shù)據(jù)放在內(nèi)存中是沒有辦法應(yīng)對一些災(zāi)難性的故障的，比如機房停機籍茧，停電等院水。一旦出現(xiàn)災(zāi)難性故障的時候檬某，就會丟失所有數(shù)據(jù)。
如果通過持久化將數(shù)據(jù)備份到磁盤上去民傻，然后定期同步和備份到一些云存儲服務(wù)上去漓踢，就可以保證不會丟失全部數(shù)據(jù)喧半，還是可以恢復(fù)大部分?jǐn)?shù)據(jù)的挺据。
Redis 持久化的意義就是用來做數(shù)據(jù)備份和故障恢復(fù)的扁耐。
Redis 持久化機制的原理
RDB 和 AOF 兩種持久化機制的介紹
RDB 持久化機制婉称，對 Redis 中的數(shù)據(jù)進(jìn)行周期性的持久化 王暗，RDB 的執(zhí)行步驟
- Redis 調(diào)用系統(tǒng)函數(shù) fork() 瘫筐，創(chuàng)建一個子進(jìn)程
- 子進(jìn)程將數(shù)據(jù)集寫入到一個臨時 RDB 文件中
- 當(dāng)子進(jìn)程完成對臨時 RDB 文件的寫入時策肝，Redis 用新的臨時 RDB 文件* * 替換原來的 RDB 文件之众，并刪除舊 RDB 文件
AOF 持久化機制棺禾，對每條寫入命令作為日志膘婶，以 append-only 的模式寫入一個日志文件中悬襟，在 Redis 重啟的時候脊岳，可以通過回放 AOF 日志中的寫入指令來重新構(gòu)建整個數(shù)據(jù)集。
如果我們想要 Redis 僅僅作為純內(nèi)存的緩存來用奶躯，那么可以禁止 RDB 和 AOF 所有的持久化機制 嘹黔。
通過 RDB 或者 AOF 都可以將 Redis 內(nèi)存中的數(shù)據(jù)持久化到磁盤上，然后將這些持久化數(shù)據(jù)備份到云服務(wù)上浙值，如果 Redis 掛了檩小，本地內(nèi)存和磁盤上的數(shù)據(jù)都丟了规求，可以從云服務(wù)上拉取持久化數(shù)據(jù)阻肿，放到指定的目錄丛塌，然后重新啟動 Redis，Redis 就會根據(jù)持久化文件中的數(shù)據(jù)去恢復(fù)內(nèi)存數(shù)據(jù)啡捶，繼續(xù)對外提供服務(wù)瞎暑。
如果同時使用 RDB 和 AOF 兩種持久化機制了赌，那么在 Redis 重啟的時候揍拆，會使用 AOF 來重新構(gòu)建數(shù)據(jù)，因為 AOF 中的數(shù)據(jù)更加完整贮喧。
RDB 持久化機制的優(yōu)點
RDB 周期性的生成持久化數(shù)據(jù)文件，非常適合做冷備谓形，可以將這種完整的數(shù)據(jù)文件發(fā)送到一些遠(yuǎn)程的云服務(wù)上去寒跳，以預(yù)定好的備份策略來定期備份 Redis 中的數(shù)據(jù)童太。
RDB 對 Redis 對外提供的讀寫服務(wù)影響非常小书释，可以讓 Redis 保持高性能爆惧，因為 Redis 主進(jìn)程只需要周期性的 fork 一個子進(jìn)程扯再，讓子進(jìn)程執(zhí)行磁盤IO操作來進(jìn)行 RDB 持久化叔收，不會每次都影響 Redis 的讀寫服務(wù)饺律。
相對于 AOF 持久化機制來說复濒，直接基于 RDB 數(shù)據(jù)文件來重啟和恢復(fù) Redis 進(jìn)程巧颈，更加快速砸泛，因為 RDB 存放的就是一份數(shù)據(jù)文件唇礁，而 AOF 存放的是指令日志盏筐，做數(shù)據(jù)恢復(fù)的時候琢融，需要回放和執(zhí)行所有的指令日志漾抬，來恢復(fù)內(nèi)存數(shù)據(jù)奋蔚。
RDB持久化機制的缺點
如果想要在 Redis 故障時泊碑，盡可能少的丟失數(shù)據(jù)馒过，那么 RDB 沒有 AOF 好腹忽。一般來說，RDB 數(shù)據(jù)快照文件葫录，都是每隔5分鐘米同，或者更長時間生成一次面粮，這個時候就得接受一旦 Redis 進(jìn)程宕機熬苍，那么會丟失最近5分鐘的數(shù)據(jù)
RDB 每次在 fork 子進(jìn)程來執(zhí)行 RDB 快照數(shù)據(jù)文件生成的時候，如果數(shù)據(jù)文件特別大似枕，可能會導(dǎo)致對客戶端提供的服務(wù)暫停數(shù)毫秒，或者甚至數(shù)秒
AOF持久化機制的優(yōu)點
AOF 可以更好的保護(hù)數(shù)據(jù)不丟失冗恨，一般 AOF 會每隔1秒掀抹，通過一個后臺線程執(zhí)行一次 fsync 操作傲武，最多丟失1秒鐘的數(shù)據(jù)
AOF 日志文件以 append-only 模式寫入揪利，所以沒有任何磁盤尋址的開銷，寫入性能非常高甜刻，而且文件不容易破損得院，即使文件尾部破損祥绞，也很容易修復(fù)
AOF 重寫的時候就谜，Redis 會開啟一個子線程執(zhí)行丧荐，根據(jù)當(dāng)前的內(nèi)存數(shù)據(jù)創(chuàng)建日志文件弓坞。在創(chuàng)建新日志文件的時候渡冻，老的日志文件還是照常寫入族吻。當(dāng)新的日志文件創(chuàng)建完成超歌，再交換新老日志文件即可巍举。
AOF 日志文件的命令通過非常可讀的方式進(jìn)行記錄炭分，這個特性非常適合做災(zāi)難性的誤刪除的緊急恢復(fù)欠窒。比如某人不小心用flushall 命令清空了所有數(shù)據(jù)岖妄，只要這個時候后臺 rewrite 還沒有發(fā)生荐虐，那么就可以立即拷貝 AOF 文件福扬，將最后一條 flushall 命令給刪了铛碑，然后再將該 AOF 文件放回去汽烦，就可以自動恢復(fù)所有數(shù)據(jù)
AOF持久化機制的缺點
對于同一份數(shù)據(jù)來說俗冻，AOF 日志文件通常比 RDB 數(shù)據(jù)快照文件更大
AOF 開啟后迄薄，支持的寫 QPS 會比 RDB 支持的寫 QPS 低讥蔽，因為 AOF 一般會配置成每秒 fsync 一次日志文件，當(dāng)然，每秒一次 fsync戳护，性能也還是很高的
RDB和AOF到底該如何選擇
不要僅僅使用 RDB，因為那樣會導(dǎo)致你丟失很多數(shù)據(jù)
也不要僅僅使用 AOF铺董，因為那樣有兩個問題精续，第一重付，你通過 AOF 做冷備确垫，沒有 RDB 做冷備來的恢復(fù)速度更快; 第二翔冀，RDB每次簡單粗暴生成數(shù)據(jù)快照纤子，更加健壯，可以避免 AOF 這種復(fù)雜的備份和恢復(fù)機制的 bug
綜合使用 AOF 和 RDB 兩種持久化機制象颖，用 AOF 來保證數(shù)據(jù)不丟失说订，作為數(shù)據(jù)恢復(fù)的第一選擇；用 RDB 來做冷備潮瓶，在 AOF 文件都丟失或損壞不可用的時候陶冷，還可以使用 RDB 來進(jìn)行快速的數(shù)據(jù)恢復(fù)
