RDB和AOF都是對服務(wù)器中所有數(shù)據(jù)庫而言的插龄，和redisDb一樣愿棋，是在redisServer結(jié)構(gòu)體下的同一層級。
RDB
由于redis是內(nèi)存型數(shù)據(jù)庫均牢，所以當(dāng)服務(wù)器進程意外終止時糠雨，數(shù)據(jù)庫中保存的信息將不會存在（比如使用redis管理會話信息的系統(tǒng)，當(dāng)redis服務(wù)器宕機會導(dǎo)致所有用戶的會話信息丟失膨处，導(dǎo)致重新登陸或者其他的問題）见秤，為了防止這一問題，redis引入了RDB持久化真椿，將數(shù)據(jù)庫狀態(tài)信息保存在硬盤中鹃答，從而實現(xiàn)redis服務(wù)器宕機后能夠從硬盤中自動恢復(fù)大部分?jǐn)?shù)據(jù)。 RDB可以手動通過指令創(chuàng)建突硝，也可以通過配置使redis服務(wù)器定期自動更新RDB文件测摔。
1. 手動創(chuàng)建
手動創(chuàng)建可以使用BGSAVE和SAVE兩個命令，他們之間的區(qū)別在于前者是通過fork一個子進程來創(chuàng)建RDB文件，不會導(dǎo)致redis服務(wù)器阻塞從而不能處理任何請求锋八，需要注意的是浙于，RDB持久化命令只能有單例執(zhí)行，不能同時執(zhí)行兩個持久化命令挟纱，否則會被服務(wù)器拒絕羞酗。
2.自動創(chuàng)建
在save選項中配置如下信息：
save 60 100 這樣表示在60秒內(nèi)如果進行了100次改動則進行持久化，save配置可以配置多行紊服，多個持久化配置之間的關(guān)系是只要滿足其中的一個那么就進行持久化檀轨。
redis的這個保存參數(shù)很值得借鑒，我們可以同時實現(xiàn)對低頻和高頻操作的持久化欺嗤。
redis服務(wù)器通過維護一個dirty計數(shù)器和lastsave來記錄某個時間段內(nèi)修改了多少次参萄，這兩個參數(shù)和redisDb結(jié)構(gòu)體在同一層級，因此可以知道記錄的是整個redis所有的數(shù)據(jù)庫的修改煎饼。redis會自動維護一個時間差讹挎，每次檢查時都會將之前的時間差和現(xiàn)在的時間相加從而判斷是否達到了配置中指定的時間長度，如果達到則判斷dirty是否達到指定次數(shù)吆玖，兩者都達到則進行一次RDB持久化操作筒溃，同時將dirty值重置為0。
AOF文件
AOF是通過保存服務(wù)器收到的命令來記錄數(shù)據(jù)庫的狀態(tài)沾乘，通過將命令追加到文件中铡羡，在服務(wù)器啟動時在創(chuàng)建一個偽客戶端從AOF文件中讀取命令從而實現(xiàn)恢復(fù)服務(wù)器狀態(tài)。
AOF文件的寫入配置有appendfsync選項來決定意鲸，當(dāng)設(shè)置為always時，服務(wù)器都會將緩沖區(qū)中的指令寫入到AOF文件中尽爆，同事同步AOF文件怎顾，效率最低但是最安全；設(shè)置為everysec時漱贱，服務(wù)器同樣是每個事件循環(huán)時會將緩沖區(qū)中的內(nèi)容寫入到AOF文件中槐雾，但是是每隔一秒才會同步AOF文件，犧牲了一定的數(shù)據(jù)可用性幅狮，提高性能募强，比較折中的方案；設(shè)置為no時崇摄，該模式速度最快擎值，但是由于服務(wù)器不會主動去同步AOF文件，由操作系統(tǒng)來控制AOF文件的同步逐抑，所以可能會有很多條指令被保存在了系統(tǒng)緩存中鸠儿，當(dāng)服務(wù)器宕機時，這種方案損失的數(shù)據(jù)也是最多的。
AOF通過存指令來實現(xiàn)服務(wù)器狀態(tài)的恢復(fù)也是有一定的弊端的进每，比如汹粤，可能多條指令同時對一個鍵進行了更新，但是最后這個鍵對應(yīng)的數(shù)據(jù)被改來改去還是原來的樣子田晚，這樣就會導(dǎo)致AOF文件中存了很多不必要的指令嘱兼。
為了解決這個問題，redis采用了AOF文件重寫贤徒，當(dāng)開啟AOF重寫時芹壕，服務(wù)器會再創(chuàng)建一個AOF重寫緩沖區(qū)來保存執(zhí)行的指令，然后經(jīng)過分析后泞莉，合并無效的指令寫入到新的AOF文件中哪雕。
