Redis持久化備份數(shù)據(jù)的方式有兩種：RDB(Redis DataBase) 卧波、 AOF(Append Only File).
RDB
在指定時間間隔內(nèi)当纱，將內(nèi)存中的數(shù)據(jù)集快照寫入磁盤缎除，也就是Snapshot快照钦讳，它恢復(fù)時是將快照文件直接讀到內(nèi)存中锋八，來達(dá)到恢復(fù)數(shù)據(jù)的镰吆。
如何持久化
Redis會單獨(dú)創(chuàng)建(fork)一個子進(jìn)程來進(jìn)行持久化磺浙，會先將數(shù)據(jù)寫進(jìn)一個臨時文件中洪囤，等到持久化過程結(jié)束了，再用這個臨時文件替換上次持久化好的文件撕氧。在這個過程中瘤缩，只有子進(jìn)程來負(fù)責(zé)IO操作，主進(jìn)程仍然處理客戶端的請求伦泥，這就確保了極高的性能剥啤。
Snapshot
在默認(rèn)情況下， Redis 將數(shù)據(jù)庫快照保存在名字為 dump.rdb 的二進(jìn)制文件中不脯。通過觸發(fā)快照的形式府怯，來做到將指定時間間隔內(nèi)的數(shù)據(jù)持久化到dump.rdb。例如防楷，可以2分鐘內(nèi)持久化一次牺丙，將對數(shù)據(jù)庫的寫操作，備份到磁盤上的dump.rdb。
RDB優(yōu)點(diǎn)與缺點(diǎn)
優(yōu)點(diǎn)
- 如果要進(jìn)行大規(guī)模數(shù)據(jù)的恢復(fù)冲簿，RDB方式要比AOF方式恢復(fù)速度要快粟判。
- RDB可以最大化Redis性能，父進(jìn)程做的就是fork子進(jìn)程峦剔，然后繼續(xù)接受客戶端請求档礁，讓子進(jìn)程負(fù)責(zé)持久化操作，父進(jìn)程無需進(jìn)行IO操作羊异。
- RDB是一個非常緊湊(compact)的文件,它保存了某個時間點(diǎn)的數(shù)據(jù)集事秀，非常適合用作備份，同時也非常適合用作災(zāi)難性恢復(fù)野舶，它只有一個文件易迹，內(nèi)容緊湊，通過備份原文件到本機(jī)外的其他主機(jī)上平道，一旦本機(jī)發(fā)生宕機(jī)睹欲，就能將備份文件復(fù)制到redis安裝目錄下，通過啟用服務(wù)就能完成數(shù)據(jù)的恢復(fù)一屋。
缺點(diǎn)
- RDB這種持久化方式不太適應(yīng)對數(shù)據(jù)完整性要求嚴(yán)格的情況窘疮，因?yàn)椋M管我們可以用過修改快照實(shí)現(xiàn)持久化的頻率冀墨，但是要持久化的數(shù)據(jù)是一段時間內(nèi)的整個數(shù)據(jù)集的狀態(tài)闸衫，如果在還沒有觸發(fā)快照時，本機(jī)就宕機(jī)了诽嘉，那么對數(shù)據(jù)庫所做的寫操作就隨之而消失了并沒有持久化本地dump.rdb文件中蔚出。
- 每次進(jìn)行RDB時，父進(jìn)程都會fork一個子進(jìn)程虫腋，由子進(jìn)程來進(jìn)行實(shí)際的持久化操作骄酗，如果數(shù)據(jù)集龐大，那么fork出子進(jìn)程的這個過程將是非常耗時的悦冀，就會出現(xiàn)服務(wù)器暫颓鞣客戶端請求，將內(nèi)存中的數(shù)據(jù)復(fù)制一份給子進(jìn)程盒蟆，讓子進(jìn)程進(jìn)行持久化操作踏烙。
AOF
以日志的形式記錄Redis每一個寫操作,將Redis執(zhí)行過的所有寫指令記錄下來（讀操作不記錄），只許追加文件不可以改寫文件历等，redis啟動之后會讀取appendonly.aof文件來實(shí)現(xiàn)重新恢復(fù)數(shù)據(jù)宙帝，完成恢復(fù)數(shù)據(jù)的工作。默認(rèn)不開啟募闲，需要將redis.conf中的appendonly no改為yes啟動Redis步脓。
持久化
appendfsync always:每修改同步，每一次發(fā)生數(shù)據(jù)變更都會持久化到磁盤上，性能較差靴患，但數(shù)據(jù)完整性較好仍侥。
appendfsync everysec: 每秒同步，每秒內(nèi)記錄操作鸳君，異步操作农渊，如果一秒內(nèi)宕機(jī)，有數(shù)據(jù)丟失或颊。
appendfsync no:不同步砸紊。
數(shù)據(jù)恢復(fù)
重啟Redis時，如果dump.rdb與appendfsync.aof同時都存在時囱挑，Redis會自動讀取appendfsync.aof文件醉顽，通過該文件中對數(shù)據(jù)庫的日志操作，來實(shí)現(xiàn)數(shù)據(jù)的恢復(fù)平挑。當(dāng)然如果該文件被破壞游添，我們可以通過redis-check-aof工具來修復(fù)，如redis-check-aof --fix能修復(fù)破損的appendfsync.aof文件通熄，當(dāng)然如果dump.rdb文件有破損唆涝，我們也可以用redis-check-rdb工具來修復(fù)，如果appendfsync.aof文件破損了唇辨，是啟動不客戶端的廊酣，也就是無法完成數(shù)據(jù)的恢復(fù)。
重寫
當(dāng)然如果AOF 文件一直被追加赏枚，這就可能導(dǎo)致AOF文件過于龐大亡驰。因此，為了避免這種狀況嗡贺，Redis新增了重寫機(jī)制隐解，當(dāng)AOF文件的大小超過所指定的閾值時鞍帝，Redis會自動啟用AOF文件的內(nèi)容壓縮诫睬，只保留可以恢復(fù)數(shù)據(jù)的最小指令集，可以使用命令bgrewiteaof帕涌。
重寫原理：
AOF文件持續(xù)增長過大時摄凡，會fork出一條新進(jìn)程來將文件重寫（也是臨時文件最后再rename）,遍歷新進(jìn)程的內(nèi)存中的數(shù)據(jù)，每條記錄都會有一條set語句蚓曼，重寫aof文件的操作亲澡，并沒有讀取舊的aof文件，而是將整個內(nèi)存中的數(shù)據(jù)庫內(nèi)容用命令的方式重寫了一個新的aof文件纫版，有點(diǎn)類似于快照床绪。
觸發(fā)機(jī)制：
Redis會記錄上一次重寫時的AOF大小，默認(rèn)配置是當(dāng)AOF文件大小是上一次的一倍并且大于64m時，會觸發(fā)從寫機(jī)制癞己。
優(yōu)點(diǎn)
AOF有著多種持久化策略：
appendfsync always:每修改同步膀斋，每一次發(fā)生數(shù)據(jù)變更都會持久化到磁盤上，性能較差痹雅，但數(shù)據(jù)完整性較好仰担。
appendfsync everysec: 每秒同步，每秒內(nèi)記錄操作绩社，異步操作摔蓝，如果一秒內(nèi)宕機(jī)，有數(shù)據(jù)丟失愉耙。
appendfsync no:不同步贮尉。
AOF文件是一個只進(jìn)行追加操作的日志文件，對文件寫入不需要進(jìn)行seek劲阎，即使在追加的過程中绘盟，寫入了不完整的命令（例如：磁盤已滿），可以使用redis-check-aof工具可以修復(fù)這種問題
Redis可以在AOF文件變得過大時悯仙，會自動地在后臺對AOF進(jìn)行重寫：重寫后的新的AOF文件包含了恢復(fù)當(dāng)前數(shù)據(jù)集所需的最小命令集合龄毡。整個重寫操作是絕對安全的，因?yàn)镽edis在創(chuàng)建AOF文件的過程中锡垄，會繼續(xù)將命令追加到現(xiàn)有的AOF文件中沦零，即使在重寫的過程中發(fā)生宕機(jī)，現(xiàn)有的AOF文件也不會丟失货岭。一旦新AOF文件創(chuàng)建完畢路操，Redis就會從舊的AOF文件切換到新的AOF文件，并對新的AOF文件進(jìn)行追加操作千贯。
AOF文件有序地保存了對數(shù)據(jù)庫執(zhí)行的所有寫入操作屯仗。這些寫入操作一Redis協(xié)議的格式保存，易于對文件進(jìn)行分析搔谴；例如魁袜，如果不小心執(zhí)行了FLUSHALL命令，但只要AOF文件未被重寫敦第，通過停止服務(wù)器峰弹，移除AOF文件末尾的FLUSHALL命令，重啟服務(wù)器就能達(dá)到FLUSHALL執(zhí)行之前的狀態(tài)芜果。
缺點(diǎn)
- 對于相同的數(shù)據(jù)集來說鞠呈，AOF文件要比RDB文件大。
- 根據(jù)所使用的持久化策略來說右钾，AOF的速度要慢與RDB摧茴。一般情況下，每秒同步策略效果較好拷姿。不使用同步策略的情況下逆巍，AOF與RDB速度一樣快。
RDB與AOF如何選擇
一般來說，如果想達(dá)到足以媲美PostgreSQL的數(shù)據(jù)安全性，應(yīng)該同時使用兩種持久化方式。
有很多用戶都只使用 AOF 持久化空镜， 但我們并不推薦這種方式： 因?yàn)槎〞r生成 RDB 快照（snapshot）非常便于進(jìn)行數(shù)據(jù)庫備份， 并且 RDB 恢復(fù)數(shù)據(jù)集的速度也要比 AOF 恢復(fù)的速度要快捌朴， 除此之外吴攒， 使用 RDB 還可以避免之前提到的 AOF 程序的 bug。
如果可以承受輸分鐘內(nèi)的數(shù)據(jù)丟失砂蔽，可以只使用RDB持久化洼怔。
