Redis作為一個(gè)鍵值對(duì)內(nèi)存數(shù)據(jù)庫(kù)(NoSQL)座舍，數(shù)據(jù)都存儲(chǔ)在內(nèi)存當(dāng)中，在處理客戶端請(qǐng)求時(shí)陨帆，所有操作都在內(nèi)存當(dāng)中進(jìn)行曲秉，為什么需要持久化采蚀，以及Redis持久化的RDB方式在這篇文章講的已經(jīng)很透徹了，足以摩擦面試官了承二！
它也是Redis持久化的重要手段之一榆鼠，aof->Append Only File，只追加文件亥鸠，也就是每次處理完請(qǐng)求命令后都會(huì)將此命令追加到aof文件的末尾妆够。而RDB是壓縮成二進(jìn)制等時(shí)機(jī)開(kāi)子進(jìn)程去干這件事。
二负蚊、優(yōu)缺點(diǎn)
1神妹、優(yōu)點(diǎn)
持久化的速度快，因?yàn)槊看味贾皇亲芳蛹易保瑀db每次都全量持久化
數(shù)據(jù)相對(duì)更可靠鸵荠，丟失少，因可以配置每秒持久化伤极、每個(gè)命令執(zhí)行完就持久化
2蛹找、缺點(diǎn)
災(zāi)難性恢復(fù)的時(shí)候過(guò)慢，因?yàn)閍of每次都只追加原命令塑荒，導(dǎo)致aof文件過(guò)大熄赡，但是后面會(huì)rewrite，但是相對(duì)于rdb也是慢的齿税。
會(huì)對(duì)主進(jìn)程對(duì)外提供請(qǐng)求的效率造成影響，接收請(qǐng)求炊豪、處理請(qǐng)求凌箕、寫(xiě)aof文件這三步是串行原子執(zhí)行的。而非異步多線程執(zhí)行的词渤。Redis單線程牵舱！
三、AOF原理
1缺虐、基礎(chǔ)原理
就是每次都在aof文件后面追加命令芜壁。他與主進(jìn)程收到請(qǐng)求、處理請(qǐng)求是串行化的高氮，而非異步并行的慧妄。圖示如下
天天在用Redis，那你對(duì)Redis的AOF持久化到底了解多少呢剪芍？
在這里插入圖片描述
所以aof的頻率高的話絕逼會(huì)對(duì)Redis帶來(lái)性能影響塞淹，因?yàn)槊看味际撬⒈P(pán)操作。跟mysql一樣了罪裹。Redis每次都是先將命令放到緩沖區(qū)饱普，然后根據(jù)具體策略（每秒/每條指令/緩沖區(qū)滿）進(jìn)行刷盤(pán)操作运挫。如果配置的always，那么就是典型阻塞套耕，如果是sec谁帕，每秒的話，那么會(huì)開(kāi)一個(gè)同步線程去每秒進(jìn)行刷盤(pán)操作冯袍，對(duì)主線程影響稍小匈挖。
2、額外擴(kuò)展
其實(shí)Redis每次在寫(xiě)入AOF緩沖區(qū)之前颠猴，他都會(huì)調(diào)用flushAppendOnlyFile()关划，判斷是否需要將AOF緩沖區(qū)的內(nèi)容寫(xiě)入和同步到AOF文件中。這個(gè)決策是由配置文件的三個(gè)策略來(lái)控制的
always
everysec
no
四翘瓮、REWRITE
1贮折、為什么要rewrite？
比如我有業(yè)務(wù)很簡(jiǎn)單资盅，就來(lái)回delete set 同一個(gè)key调榄。就這個(gè)業(yè)務(wù)運(yùn)行了10年，那么aof文件將記錄無(wú)數(shù)個(gè)delete k1呵扛， set k1 xxx每庆。其實(shí)都是重復(fù)的，但是我aof每次都追加今穿，文件變成了1T大小缤灵。這時(shí)候Redis宕機(jī)了，要恢復(fù)蓝晒，你想想1TB大小的aof文件去恢復(fù)腮出，累死了。最主要的是1TB大小只記錄了兩個(gè)命令芝薇，所以壓縮其實(shí)就是來(lái)處理這件事的胚嘲。
2、4.0版本之前的rewrite
Redis4.0之前和Redis4.0的rewrite（重寫(xiě)）方式不一樣洛二，Redis4.0之前就是將aof文件中重復(fù)的命令給去掉馋劈。保留最新的命令。進(jìn)而減少aof文件大小晾嘶。比如
set k1 123set k1 345del k1set k1 789
經(jīng)過(guò)rewrite后（Redis4.0之前）妓雾，只會(huì)變成如下
3、4.0版本以及之后的rewrite
4.0之前的做法效率很是低下变擒，需要逐條命令對(duì)比君珠。4.0開(kāi)始的rewrite支持混合模式(也是就是rdb和aof一起用)，直接將rdb持久化的方式來(lái)操作將二進(jìn)制內(nèi)容覆蓋到aof文件中（rdb是二進(jìn)制娇斑，所以很胁咛怼）材部，然后再有寫(xiě)入的話還是繼續(xù)append追加到文件原始命令，等下次文件過(guò)大的時(shí)候再次rewrite（還是按照rdb持久化的方式將內(nèi)容覆蓋到aof中）唯竹。但是這種模式也是配置的乐导，默認(rèn)是開(kāi)，也可以關(guān)閉浸颓。
4物臂、rewrite觸發(fā)條件
1、手動(dòng)觸發(fā)
客戶端執(zhí)行bgrewriteaof命令
2产上、自動(dòng)觸發(fā)
通過(guò)以下兩個(gè)配置協(xié)作觸發(fā)
auto-aof-rewrite-min-size
AOF文件最小重寫(xiě)大小棵磷，只有當(dāng)AOF文件大小大于該值時(shí)候才可能重寫(xiě),4.0默認(rèn)配置64mb。
auto-aof-rewrite-percentage
當(dāng)前AOF文件大小和最后一次重寫(xiě)后的大小之間的比率等于或者等于指定的增長(zhǎng)百分比晋涣，如100代表當(dāng)前AOF文件是上次重寫(xiě)的兩倍時(shí)候才重寫(xiě)仪媒。
3、觸發(fā)滿足條件
沒(méi)有BGSAVE命令（RDB持久化）/AOF持久化在執(zhí)行
沒(méi)有BGREWRITEAOF在進(jìn)行谢鹊；
前兩點(diǎn)也就是說(shuō)只允許同時(shí)fork()一個(gè)子進(jìn)程出來(lái)干活算吩。
當(dāng)前AOF文件大小要大于server.aof_rewrite_min_size的值；
當(dāng)前AOF文件大小和最后一次重寫(xiě)后的大小之間的比率等于或者大于指定的增長(zhǎng)百分比（auto-aof-rewrite-percentage參數(shù)）
5佃扼、rewrite原理
4.0之前版本的偎巢，和4.0以及之后關(guān)閉混合模式的情況下。
天天在用Redis兼耀，那你對(duì)Redis的AOF持久化到底了解多少呢压昼？
aof_rewrite_buf：rewrite(重寫(xiě))緩沖區(qū)、aof_buf：寫(xiě)命令存放的緩沖區(qū)
開(kāi)始bgrewriteaof的時(shí)候瘤运，判斷當(dāng)前有沒(méi)有bgsave/bgrewriteaof在執(zhí)行巢音，若有，則不執(zhí)行尽超，這個(gè)再rdb篇幅也有提到，以及下面很多fork()知識(shí)在rdb都有提到梧躺∷扑看完這篇還不懂Redis的RDB持久化，你們來(lái)打我掠哥！
主進(jìn)程fork()出子進(jìn)程巩踏，在執(zhí)行fork()這個(gè)方法的時(shí)候是阻塞的，子進(jìn)程創(chuàng)建完畢后就不阻塞了
主進(jìn)程fork完子進(jìn)程后续搀，主進(jìn)程能繼續(xù)接收客戶端的請(qǐng)求塞琼，所有寫(xiě)命令依然是寫(xiě)入AOF文件緩沖區(qū)并根據(jù)配置文件的策略同步到磁盤(pán)的。
因?yàn)閒ork的子進(jìn)程僅僅共享主進(jìn)程fork()時(shí)的內(nèi)存禁舷，后期主進(jìn)程在更改內(nèi)存數(shù)據(jù)彪杉，子進(jìn)程是不可見(jiàn)的毅往。因此Redis采取重寫(xiě)緩沖區(qū)（aof_rewite_buf）保存fork之后的客戶端請(qǐng)求。防止新AOF文件生成期間丟失主進(jìn)程執(zhí)行的新命令所生成的數(shù)據(jù)派近。所以此時(shí)客戶端的寫(xiě)請(qǐng)求不僅僅寫(xiě)入原來(lái)的aof_buf緩沖區(qū)攀唯，還寫(xiě)入了重寫(xiě)緩沖區(qū)。這就是我為什么用深藍(lán)色的框給他兩框到一起的原因渴丸。
子進(jìn)程通過(guò)內(nèi)存快照的形式侯嘀，開(kāi)始生成新的aof文件。
新aof文件生成完后谱轨，子進(jìn)程向主進(jìn)程發(fā)信號(hào)戒幔。
主進(jìn)程收到信號(hào)后，會(huì)把重寫(xiě)緩沖區(qū)(aof_rewite_buf)中的數(shù)據(jù)寫(xiě)入到新的AOF文件（主要是避免這部分?jǐn)?shù)據(jù)丟失）
使用新的AOF文件覆蓋舊的AOF文件土童，且標(biāo)記AOF重寫(xiě)完成诗茎。
五、RDB-AOF混合持久化
redis4.0之后才支持娜扇，默認(rèn)開(kāi)啟
1错沃、優(yōu)點(diǎn)
混合持久化結(jié)合了RDB持久化 和 AOF 持久化的優(yōu)點(diǎn),采取了rdb的文件小易于災(zāi)難恢復(fù)，同時(shí)結(jié)合AOF雀瓢，增量的數(shù)據(jù)以AOF方式保存了枢析，數(shù)據(jù)更少的丟失。
2刃麸、缺點(diǎn)
兼容性差醒叁，一旦開(kāi)啟了混合持久化，在4.0之前版本都不識(shí)別該aof文件泊业，同時(shí)由于前部分是RDB格式把沼，需要專業(yè)的工具來(lái)閱讀，因?yàn)槭嵌M(jìn)制吁伺，所以閱讀性較差饮睬。
3、原理
需要先掌握看完這篇還不懂Redis的RDB持久化篮奄，你們來(lái)打我捆愁！和此篇幅的aof
混合持久化也是通過(guò)bgrewriteaof完成的，所以基本流程和上述一樣窟却。不同的是當(dāng)開(kāi)啟混合模式時(shí)昼丑，fork出的子進(jìn)程先將共享的內(nèi)存副本全量以RDB的方式寫(xiě)入aof。這樣提高了速度也極大的縮小了aof文件（畢竟都是二進(jìn)制）夸赫。寫(xiě)完還是通知主進(jìn)程菩帝，然后再將重寫(xiě)緩沖區(qū)的內(nèi)容以AOF方式寫(xiě)入到文件，然后替換舊的aof文件。也就是說(shuō)這種模式下的aof文件發(fā)生rewrite后前半部分是rdb格式（REDIS開(kāi)頭的二進(jìn)制數(shù)據(jù)）呼奢，后半部分是正常的aof追加的命令（重寫(xiě)緩沖區(qū)里的）宜雀。
4、數(shù)據(jù)恢復(fù)
會(huì)優(yōu)先看是否存在aof文件控妻，若存在則先按照aof文件恢復(fù)州袒，因?yàn)閍of畢竟比rdb全。若aof不存在弓候，則才會(huì)查找rdb是否存在郎哭。這是默認(rèn)的機(jī)制。畢竟aof文件也rewrite成rdb二進(jìn)制格式菇存，文件小夸研，易于回復(fù)。所以redis會(huì)優(yōu)先采取aof依鸥。
六亥至、總結(jié)
此篇都是重點(diǎn)，廢話很少贱迟。沒(méi)啥可總結(jié)的姐扮。
最后小編整理了一套技術(shù)資料不僅能精準(zhǔn)消除技術(shù)盲點(diǎn)、累計(jì)面試經(jīng)驗(yàn)衣吠，更可以攻克JVM茶敏、Spring、分布式缚俏、微服務(wù)等技術(shù)難題惊搏。
