嗯耸携，其實(shí)很早之前就想寫這篇文章了将宪，稍稍接觸過redis的人都知道redis的兩種持久化方式以及對應(yīng)的配置过椎。但是我還是想說一下面試中的redis的此類問題，例如面試官問你荸频，eg:我們都知道redis的幾種持久化方式菱肖，請簡述一下他們的區(qū)別和優(yōu)缺點(diǎn)。我們經(jīng)常接觸旭从，但是如果面試沒做準(zhǔn)備的話還是很容易被問懵稳强，其實(shí)我最想強(qiáng)調(diào)的是，不管你有多少工作經(jīng)驗(yàn)和悦，對這些知識點(diǎn)你掌握如何退疫，只要去面試就一定一定得復(fù)習(xí)全備，因?yàn)檫@一類得東西我們實(shí)際上不常用鸽素，至少不可能說是天天用褒繁。

我做面試官的時(shí)候一般會從幾個(gè)緯度來判斷一個(gè)人是否能勝任一個(gè)崗位：知識面廣度，專業(yè)深度馍忽，邏輯思維棒坏。但是總有一些公司的技術(shù)面試習(xí)慣性的去用自己的認(rèn)知去否定別人的認(rèn)知燕差，一千個(gè)讀者就有一千個(gè)哈姆雷特，每個(gè)人對一個(gè)相同的知識點(diǎn)的歸納是不同的坝冕，我其實(shí)很是討厭此類人徒探，當(dāng)然此類人往往出現(xiàn)在小公司的情況比較多，先進(jìn)公司然后當(dāng)上了小管理喂窟，其實(shí)大家不用被此類人影響到對知識點(diǎn)的認(rèn)知刹帕。

持久化之RDB

定義：在指定的時(shí)間間隔內(nèi)生成數(shù)據(jù)集的時(shí)間點(diǎn)快照（point-in-time snapshot）

RDB 的優(yōu)點(diǎn)

1.RDB 是一個(gè)非常緊湊（compact）的文件，它保存了 Redis 在某個(gè)時(shí)間點(diǎn)上的數(shù)據(jù)集谎替。 這種文件非常適合用于進(jìn)行備份： 比如說偷溺，你可以在最近的 24 小時(shí)內(nèi)，每小時(shí)備份一次 RDB 文件钱贯，并且在每個(gè)月的每一天挫掏，也備份一個(gè) RDB 文件。 這樣的話秩命，即使遇上問題尉共，也可以隨時(shí)將數(shù)據(jù)集還原到不同的版本。

2.RDB 非常適用于災(zāi)難恢復(fù)（disaster recovery）：它只有一個(gè)文件弃锐，并且內(nèi)容都非常緊湊袄友，可以（在加密后）將它傳送到別的數(shù)據(jù)中心，或者亞馬遜 S3 中霹菊。

3.RDB 可以最大化 Redis 的性能：父進(jìn)程在保存 RDB 文件時(shí)唯一要做的就是?fork?出一個(gè)子進(jìn)程剧蚣，然后這個(gè)子進(jìn)程就會處理接下來的所有保存工作，父進(jìn)程無須執(zhí)行任何磁盤 I/O 操作旋廷。

4.RDB 在恢復(fù)大數(shù)據(jù)集時(shí)的速度比 AOF 的恢復(fù)速度要快鸠按。

RDB 的缺點(diǎn)

如果你需要盡量避免在服務(wù)器故障時(shí)丟失數(shù)據(jù)，那么 RDB 不適合你饶碘。 雖然 Redis 允許你設(shè)置不同的保存點(diǎn)（save point）來控制保存 RDB 文件的頻率目尖， 但是， 因?yàn)镽DB 文件需要保存整個(gè)數(shù)據(jù)集的狀態(tài)扎运， 所以它并不是一個(gè)輕松的操作瑟曲。 因此你可能會至少 5 分鐘才保存一次 RDB 文件。 在這種情況下豪治， 一旦發(fā)生故障停機(jī)洞拨， 你就可能會丟失好幾分鐘的數(shù)據(jù)。

每次保存 RDB 的時(shí)候鬼吵，Redis 都要?fork()?出一個(gè)子進(jìn)程扣甲，并由子進(jìn)程來進(jìn)行實(shí)際的持久化工作。 在數(shù)據(jù)集比較龐大時(shí)齿椅，?fork()?可能會非常耗時(shí)琉挖，造成服務(wù)器在某某毫秒內(nèi)停止處理客戶端； 如果數(shù)據(jù)集非常巨大涣脚，并且 CPU 時(shí)間非常緊張的話示辈，那么這種停止時(shí)間甚至可能會長達(dá)整整一秒。 雖然 AOF 重寫也需要進(jìn)行?fork()?遣蚀，但無論 AOF 重寫的執(zhí)行間隔有多長矾麻，數(shù)據(jù)的耐久性都不會有任何損失。

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

1.使用 AOF 持久化會讓 Redis 變得非常耐久（much more durable）：你可以設(shè)置不同的?fsync?策略芭梯，比如無?fsync?险耀，每秒鐘一次?fsync?，或者每次執(zhí)行寫入命令時(shí)?fsync?玖喘。 AOF 的默認(rèn)策略為每秒鐘?fsync?一次甩牺，在這種配置下，Redis 仍然可以保持良好的性能累奈，并且就算發(fā)生故障停機(jī)贬派，也最多只會丟失一秒鐘的數(shù)據(jù)（?fsync?會在后臺線程執(zhí)行，所以主線程可以繼續(xù)努力地處理命令請求）澎媒。

AOF 文件是一個(gè)只進(jìn)行追加操作的日志文件（append only log）搞乏， 因此對 AOF 文件的寫入不需要進(jìn)行?seek?， 即使日志因?yàn)槟承┰蚨宋磳懭胪暾拿睿ū热鐚懭霑r(shí)磁盤已滿戒努，寫入中途停機(jī)请敦，等等），?redis-check-aof?工具也可以輕易地修復(fù)這種問題储玫。

Redis 可以在 AOF 文件體積變得過大時(shí)冬三，自動(dòng)地在后臺對 AOF 進(jìn)行重寫： 重寫后的新 AOF 文件包含了恢復(fù)當(dāng)前數(shù)據(jù)集所需的最小命令集合。 整個(gè)重寫操作是絕對安全的缘缚，因?yàn)?Redis 在創(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é)議的格式保存喻括， 因此 AOF 文件的內(nèi)容非常容易被人讀懂邀杏， 對文件進(jìn)行分析（parse）也很輕松。 導(dǎo)出（export） AOF 文件也非常簡單： 舉個(gè)例子， 如果你不小心執(zhí)行了?FLUSHALL?命令望蜡， 但只要 AOF 文件未被重寫唤崭， 那么只要停止服務(wù)器， 移除 AOF 文件末尾的?FLUSHALL?命令脖律， 并重啟 Redis 谢肾， 就可以將數(shù)據(jù)集恢復(fù)到?FLUSHALL?執(zhí)行之前的狀態(tài)。

AOF 的缺點(diǎn)

對于相同的數(shù)據(jù)集來說小泉，AOF 文件的體積通常要大于 RDB 文件的體積芦疏。

根據(jù)所使用的?fsync?策略，AOF 的速度可能會慢于 RDB 微姊。 在一般情況下酸茴， 每秒?fsync?的性能依然非常高， 而關(guān)閉?fsync?可以讓 AOF 的速度和 RDB 一樣快兢交， 即使在高負(fù)荷之下也是如此薪捍。 不過在處理巨大的寫入載入時(shí)，RDB 可以提供更有保證的最大延遲時(shí)間（latency）魁淳。

AOF 在過去曾經(jīng)發(fā)生過這樣的 bug ： 因?yàn)閭€(gè)別命令的原因飘诗，導(dǎo)致 AOF 文件在重新載入時(shí)，無法將數(shù)據(jù)集恢復(fù)成保存時(shí)的原樣界逛。 （舉個(gè)例子昆稿，阻塞命令?BRPOPLPUSH?就曾經(jīng)引起過這樣的 bug 。） 測試套件里為這種情況添加了測試： 它們會自動(dòng)生成隨機(jī)的息拜、復(fù)雜的數(shù)據(jù)集溉潭， 并通過重新載入這些數(shù)據(jù)來確保一切正常。 雖然這種 bug 在 AOF 文件中并不常見少欺， 但是對比來說喳瓣， RDB 幾乎是不可能出現(xiàn)這種 bug 的。

然后咱以上就是rdb和aof的優(yōu)缺點(diǎn)赞别，簡單用自己的話來描述一下吧

RDB的優(yōu)點(diǎn)：簡稱“3更”

1.體積更形飞隆：相同的數(shù)據(jù)量rdb數(shù)據(jù)比aof的小，因?yàn)閞db是緊湊型文件

2.恢復(fù)更快：因?yàn)閞db是數(shù)據(jù)的快照仿滔，基本上就是數(shù)據(jù)的復(fù)制惠毁，不用重新讀取再寫入內(nèi)存

3.性能更高:父進(jìn)程在保存rdb時(shí)候只需要fork一個(gè)子進(jìn)程，無需父進(jìn)程的進(jìn)行其他io操作崎页，也保證了服務(wù)器的性能鞠绰。

缺點(diǎn)：

1.故障丟失:因?yàn)閞db是全量的，我們一般是使用shell腳本實(shí)現(xiàn)30分鐘或者1小時(shí)或者每天對redis進(jìn)行rdb備份飒焦，（注蜈膨，也可以是用自帶的策略），但是最少也要5分鐘進(jìn)行一次的備份，所以當(dāng)服務(wù)死掉后翁巍，最少也要丟失5分鐘的數(shù)據(jù)驴一。

2.耐久性差:相對aof的異步策略來說，因?yàn)閞db的復(fù)制是全量的曙咽，即使是fork的子進(jìn)程來進(jìn)行備份蛔趴，當(dāng)數(shù)據(jù)量很大的時(shí)候?qū)Υ疟P的消耗也是不可忽視的挑辆，尤其在訪問量很高的時(shí)候例朱，fork的時(shí)間也會延長，導(dǎo)致cpu吃緊鱼蝉，耐久性相對較差洒嗤。

aof的優(yōu)點(diǎn)

1.數(shù)據(jù)保證：我們可以設(shè)置fsync策略，一般默認(rèn)是everysec魁亦，也可以設(shè)置每次寫入追加渔隶，所以即使服務(wù)死掉了，咱們也最多丟失一秒數(shù)據(jù)

2.自動(dòng)縮薪嗄巍：當(dāng)aof文件大小到達(dá)一定程度的時(shí)候间唉，后臺會自動(dòng)的去執(zhí)行aof重寫，此過程不會影響主進(jìn)程利术，重寫完成后呈野，新的寫入將會寫到新的aof中，舊的就會被刪除掉印叁。但是此條如果拿出來對比rdb的話還是沒有必要算成優(yōu)點(diǎn)被冒，只是官網(wǎng)顯示成優(yōu)點(diǎn)而已。

缺點(diǎn)呢：和rdb相反嘛轮蜕，畢竟只有兩種昨悼。

1.性能相對較差：它的操作模式?jīng)Q定了它會對redis的性能有所損耗

2.體積相對更大：盡管是將aof文件重寫了，但是畢竟是操作過程和操作結(jié)果仍然有很大的差別跃洛，體積也毋庸置疑的更大率触。

3.恢復(fù)速度更慢：

所以我給出的問題的答案呢：redis有兩種持久化方式，aof和rdb汇竭，aof相當(dāng)于日志記錄操作命令葱蝗，rdb相當(dāng)于數(shù)據(jù)的快照。安全性來講由于aof的記錄能夠精確到秒級追加甚至逐條追加韩玩，而rdb只能是全量復(fù)制垒玲，aof明顯高于rdb。但是從性能來講rdb就略勝一籌找颓，rdb是redis性能最大化的體現(xiàn)合愈，它不用每秒監(jiān)控是否有數(shù)據(jù)寫入，當(dāng)達(dá)到觸發(fā)條件后就自動(dòng)fork一個(gè)子進(jìn)程進(jìn)行全量更新，速度也很快佛析。容災(zāi)回復(fù)方面rdb更是能夠快速的恢復(fù)數(shù)據(jù)益老，而aof需要讀取再寫入，相對慢了很多寸莫。

然后面試官就會問你：所以你選擇是什么捺萌？

aof！１炀ァＬ掖俊！Ｅ怠Ｌ埂（在中國數(shù)據(jù)安全是最重要的）

本文純手打，如有轉(zhuǎn)發(fā)請標(biāo)明出處棒拂，謝謝配合伞梯。