如果你認(rèn)為Redis是1個(gè)key value store, 那可能會(huì)用它來(lái)代替MySQL；如果認(rèn)為它是1個(gè)可以持久化的cache, 可能只是它保存1些頻繁訪問的臨時(shí)數(shù)據(jù)。

       我們來(lái)假想1個(gè)問題，通過(guò)前面的介紹，我們知道了redis與memcached都可以當(dāng)作緩存，提高訪問效力，那末如果對(duì)突然斷電或其他故障，那末是否是意味著我們的緩存數(shù)據(jù)要丟失？

       redis是1個(gè)支持持久化的內(nèi)存數(shù)據(jù)庫(kù)，也就是說(shuō)redis需要常常將內(nèi)存中的數(shù)據(jù)同步到磁盤來(lái)保證持久化。也就是說(shuō)緩存和我們的數(shù)據(jù)庫(kù)之間有著交互，我們可以把緩存中的數(shù)據(jù)保存下來(lái)這也就是redis比其他緩存強(qiáng)大的地方：持久化。

       redis支持兩種持久化方式，1種是 RDB（快照）也是默許方式，另外一種是Append-only file（縮寫aof）的方式。
       RDB 持久化可以在指定的時(shí)間間隔內(nèi)生成數(shù)據(jù)集的時(shí)間點(diǎn)快照（point-in-time snapshot）。

       AOF 持久化記錄服務(wù)器履行的所有寫操作命令，并在服務(wù)器啟動(dòng)時(shí)，通太重新履行這些命令來(lái)還原數(shù)據(jù)集。 AOF 文件中的命令全部以 Redis 協(xié)議的格式來(lái)保存，新命令會(huì)被追加到文件的末尾。 Redis 還可以在后臺(tái)對(duì) AOF 文件進(jìn)行重寫（rewrite），使得 AOF 文件的體積不會(huì)超越保存數(shù)據(jù)集狀態(tài)所需的實(shí)際大小。

       Redis 還可以同時(shí)使用 AOF 持久化和 RDB 持久化。 在這類情況下， 當(dāng) Redis 重啟時(shí)， 它會(huì)優(yōu)先使用 AOF 文件來(lái)還原數(shù)據(jù)集， 由于 AOF 文件保存的數(shù)據(jù)集通常比 RDB 文件所保存的數(shù)據(jù)集更完全。你乃至可以關(guān)閉持久化功能，讓數(shù)據(jù)只在服務(wù)器運(yùn)行時(shí)存在。

RDB

       快照是默許的持久化方式。這類方式是就是將內(nèi)存中數(shù)據(jù)以快照的方式寫入到2進(jìn)制文件中,默許的文件名為dump.rdb。可以通過(guò)配置設(shè)置自動(dòng)做快照持久 化的方式。
       我們可以配置redis在n秒內(nèi)如果超過(guò)m個(gè)key被修改就自動(dòng)做快照，下面是默許的快照保存配置

RDB 快照運(yùn)作進(jìn)程

       在默許情況下， Redis 將數(shù)據(jù)庫(kù)快照保存在名字為 dump.rdb 的2進(jìn)制文件中。你可以對(duì) Redis 進(jìn)行設(shè)置， 讓它在“ N 秒內(nèi)數(shù)據(jù)集最少有 M 個(gè)改動(dòng)”這1條件被滿足時(shí)， 自動(dòng)保存1次數(shù)據(jù)集。

       你也能夠通過(guò)調(diào)用 SAVE 或 BGSAVE ， 手動(dòng)讓 Redis 進(jìn)行數(shù)據(jù)集保存操作。比如說(shuō)， 以下設(shè)置會(huì)讓 Redis 在滿足“ 60 秒內(nèi)有最少有 1000 個(gè)鍵被改動(dòng)”這1條件時(shí)， 自動(dòng)保存1次數(shù)據(jù)集：

       當(dāng) Redis 需要保存 dump.rdb 文件時(shí)， 服務(wù)器履行以下操作：

       Redis 調(diào)用 fork() ，同時(shí)具有父進(jìn)程和子進(jìn)程。

       子進(jìn)程將數(shù)據(jù)集寫入到1個(gè)臨時(shí) RDB 文件中。
       當(dāng)子進(jìn)程完成對(duì)新 RDB 文件的寫入時(shí)，Redis 用新 RDB 文件替換原來(lái)的 RDB 文件，并刪除舊的 RDB 文件。

       這類工作方式使得 Redis 可以從寫時(shí)復(fù)制（copy-on-write）機(jī)制中獲益。

       只進(jìn)行追加操作的文件（append-only file，AOF）

AOF

       從 1.1 版本開始， Redis 增加了1種完全耐久的持久化方式： AOF 持久化。
       你可以通過(guò)修改配置文件來(lái)打開 AOF 功能：

       從現(xiàn)在開始， 每當(dāng) Redis 履行1個(gè)改變數(shù)據(jù)集的命令時(shí)（比如 SET）， 這個(gè)命令就會(huì)被追加到 AOF 文件的末尾。

       這樣的話， 當(dāng) Redis 重新啟時(shí)， 程序就能夠通太重新履行 AOF 文件中的命令來(lái)到達(dá)重建數(shù)據(jù)集的目的。

       另外一點(diǎn)需要注意的是，每次快照持久化都是將內(nèi)存數(shù)據(jù)完全寫入到磁盤1次，其實(shí)不 是增量的只同步臟數(shù)據(jù)。如果數(shù)據(jù)量大的話，而且寫操作比較多，必定會(huì)引發(fā)大量的磁盤io操作，可能會(huì)嚴(yán)重影響性能。

       另外由于快照方式是在1定間隔時(shí)間做1次的，所以如果redis意外down掉的話，就會(huì)丟失最后1次快照后的所有修改。如果利用要求不能丟失任何修改的話，可以采取aof持久化方式.

AOF運(yùn)作進(jìn)程

       aof 比快照方式有更好的持久化性，是由于在使用aof持久化方式時(shí),redis會(huì)將每個(gè)收到的寫命令都通過(guò)write函數(shù)追加到文件中(默許是 appendonly.aof)。

       當(dāng)redis重啟時(shí)會(huì)通太重新履行文件中保存的寫命令來(lái)在內(nèi)存中重建全部數(shù)據(jù)庫(kù)的內(nèi)容。固然由于os會(huì)在內(nèi)核中緩存 write做的修改，所以可能不是立即寫到磁盤上。這樣aof方式的持久化也還是有可能會(huì)丟失部份修改。

       不過(guò)我們可以通過(guò)配置文件告知redis我們想要 通過(guò)fsync函數(shù)強(qiáng)迫os寫入到磁盤的時(shí)機(jī)。有3種方式以下（默許是：每秒fsync1次）

具體進(jìn)程以下
       1. redis調(diào)用fork ，現(xiàn)在有父子兩個(gè)進(jìn)程

       2. 子進(jìn)程根據(jù)內(nèi)存中的數(shù)據(jù)庫(kù)快照，往臨時(shí)文件中寫入重建數(shù)據(jù)庫(kù)狀態(tài)的命令

       3.父進(jìn)程繼續(xù)處理client要求，除把寫命令寫入到原來(lái)的aof文件中。同時(shí)把收到的寫命令緩存起來(lái)。這樣就可以保證如果子進(jìn)程重寫失敗的話其實(shí)不會(huì)出問題。

       4.當(dāng)子進(jìn)程把快照內(nèi)容寫入已命令方式寫到臨時(shí)文件中后，子進(jìn)程發(fā)信號(hào)通知父進(jìn)程。然后父進(jìn)程把緩存的寫命令也寫入到臨時(shí)文件。

       5.現(xiàn)在父進(jìn)程可使用臨時(shí)文件替換老的aof文件，并重命名，后面收到的寫命令也開始往新的aof文件中追加。

       需要注意到是重寫aof文件的操作，并沒有讀取舊的aof文件，而是將全部?jī)?nèi)存中的數(shù)據(jù)庫(kù)內(nèi)容用命令的方式重寫了1個(gè)新的aof文件,這點(diǎn)和快照有點(diǎn)類似。

       安裝Redis以后，我們會(huì)發(fā)現(xiàn)redis.conf文件，在這里面我們可以設(shè)置以上兩種持久化方式。

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

       RDB 是1個(gè)非常緊湊（compact）的文件，它保存了 Redis 在某個(gè)時(shí)間點(diǎn)上的數(shù)據(jù)集。 這類文件非常合適用于進(jìn)行備份： 比如說(shuō)，你可以在最近的 24 小時(shí)內(nèi)，每小時(shí)備份1次 RDB 文件，并且在每月的每天，也備份1個(gè) RDB 文件。

        這樣的話，即便遇上問題，也能夠隨時(shí)將數(shù)據(jù)集還原到不同的版本。RDB 非常適用于災(zāi)害恢復(fù)（disaster recovery）：它只有1個(gè)文件，并且內(nèi)容都非常緊湊，可以（在加密后）將它傳送到別的數(shù)據(jù)中心，或亞馬遜 S3 中。

       RDB 可以最大化 Redis 的性能：父進(jìn)程在保存 RDB 文件時(shí)唯1要做的就是 fork 出1個(gè)子進(jìn)程，然后這個(gè)子進(jìn)程就會(huì)處理接下來(lái)的所有保存工作，父進(jìn)程不必履行任何磁盤 I/O 操作。RDB 在恢復(fù)大數(shù)據(jù)集時(shí)的速度比 AOF 的恢復(fù)速度要快。

RDB 的缺點(diǎn)

       如果你需要盡可能避免在服務(wù)器故障時(shí)丟失數(shù)據(jù)，那末 RDB 不合適你。 雖然 Redis 允許你設(shè)置不同的保存點(diǎn)（save point）來(lái)控制保存 RDB 文件的頻率， 但是， 由于RDB 文件需要保存全部數(shù)據(jù)集的狀態(tài)， 所以它其實(shí)不是1個(gè)輕松的操作。 因此你可能會(huì)最少 5 分鐘才保存1次 RDB 文件。

        在這類情況下， 1旦產(chǎn)生故障停機(jī)， 你便可能會(huì)丟失好幾分鐘的數(shù)據(jù)。每次保存 RDB 的時(shí)候，Redis 都要 fork() 出1個(gè)子進(jìn)程，并由子進(jìn)程來(lái)進(jìn)行實(shí)際的持久化工作。

       在數(shù)據(jù)集比較龐大時(shí)， fork() 可能會(huì)非常耗時(shí)，造成服務(wù)器在某某毫秒內(nèi)停止處理客戶端； 如果數(shù)據(jù)集非常巨大，并且 CPU 時(shí)間非常緊張的話，那末這類停止時(shí)間乃至可能會(huì)長(zhǎng)達(dá)整整1秒。 雖然 AOF 重寫也需要進(jìn)行 fork() ，但不管 AOF 重寫的履行間隔有多長(zhǎng)，數(shù)據(jù)的耐久性都不會(huì)有任何損失。

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

       使用 AOF 持久化會(huì)讓 Redis 變得非常耐久（much more durable）：你可以設(shè)置不同的 fsync 策略，比如無(wú) fsync ，每秒鐘1次 fsync ，或每次履行寫入命令時(shí) fsync 。

        AOF 的默許策略為每秒鐘 fsync 1次，在這類配置下，Redis 依然可以保持良好的性能，并且就算產(chǎn)生故障停機(jī)，也最多只會(huì)丟失1秒鐘的數(shù)據(jù)（ fsync 會(huì)在后臺(tái)線程履行，所以主線程可以繼續(xù)努力地處理命令要求）。

       AOF 文件是1個(gè)只進(jìn)行追加操作的日志文件（append only log）， 因此對(duì) AOF 文件的寫入不需要進(jìn)行 seek ， 即便日志由于某些緣由而包括了未寫入完全的命令（比如寫入時(shí)磁盤已滿，寫入中途停機(jī)，等等）， redis-check-aof 工具也能夠輕易地修復(fù)這類問題。

       Redis 可以在 AOF 文件體積變得過(guò)大時(shí)，自動(dòng)地在后臺(tái)對(duì) AOF 進(jìn)行重寫： 重寫后的新 AOF 文件包括了恢復(fù)當(dāng)前數(shù)據(jù)集所需的最小命令集合。 全部重寫操作是絕對(duì)安全的，由于 Redis 在創(chuàng)建新 AOF 文件的進(jìn)程中，會(huì)繼續(xù)將命令追加到現(xiàn)有的 AOF 文件里面，即便重寫進(jìn)程中產(chǎn)生停機(jī)，現(xiàn)有的 AOF 文件也不會(huì)丟失。 而1旦新 AOF 文件創(chuàng)建終了，Redis 就會(huì)從舊 AOF 文件切換到新 AOF 文件，并開始對(duì)新 AOF 文件進(jìn)行追加操作。

       AOF 文件有序地保存了對(duì)數(shù)據(jù)庫(kù)履行的所有寫入操作， 這些寫入操作以 Redis 協(xié)議的格式保存， 因此 AOF 文件的內(nèi)容非常容易被人讀懂， 對(duì)文件進(jìn)行分析（parse）也很輕松。 導(dǎo)出（export） AOF 文件也非常簡(jiǎn)單： 舉個(gè)例子， 如果你不謹(jǐn)慎履行了 FLUSHALL 命令， 但只要 AOF 文件未被重寫， 那末只要停止服務(wù)器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重啟 Redis ， 就能夠?qū)?shù)據(jù)集恢復(fù)到 FLUSHALL 履行之前的狀態(tài)。

AOF 的缺點(diǎn)

       對(duì)相同的數(shù)據(jù)集來(lái)講，AOF 文件的體積通常要大于 RDB 文件的體積。根據(jù)所使用的 fsync 策略，AOF 的速度可能會(huì)慢于 RDB 。

       在1般情況下， 每秒 fsync 的性能仍然非常高， 而關(guān)閉 fsync 可讓 AOF 的速度和 RDB 1樣快， 即便在高負(fù)荷之下也是如此。 不過(guò)在處理巨大的寫入載入時(shí)，RDB 可以提供更有保證的最大延遲時(shí)間（latency）。

       AOF 在過(guò)去曾產(chǎn)生過(guò)這樣的 bug ： 由于個(gè)別命令的緣由，致使 AOF 文件在重新載入時(shí)，沒法將數(shù)據(jù)集恢復(fù)成保存時(shí)的原樣。 （舉個(gè)例子，阻塞命令 BRPOPLPUSH 就曾引發(fā)過(guò)這樣的 bug 。） 測(cè)試套件里為這類情況添加了測(cè)試： 它們會(huì)自動(dòng)生成隨機(jī)的、復(fù)雜的數(shù)據(jù)集， 并通太重新載入這些數(shù)據(jù)來(lái)確保1切正常。 雖然這類 bug 在 AOF 文件中其實(shí)不常見， 但是對(duì)照來(lái)講， RDB 幾近是不可能出現(xiàn)這類 bug 的。

RDB 和 AOF ,我應(yīng)當(dāng)用哪個(gè)?

       1般來(lái)講,如果想到達(dá)足以媲美 PostgreSQL 的數(shù)據(jù)安全性， 你應(yīng)當(dāng)同時(shí)使用兩種持久化功能。如果你非常關(guān)心你的數(shù)據(jù),但依然可以承受數(shù)分鐘之內(nèi)的數(shù)據(jù)丟失， 那末你可以只使用 RDB 持久化。有很多用戶都只使用 AOF 持久化， 但我們其實(shí)不推薦這類方式： 由于定時(shí)生成 RDB 快照（snapshot）非常便于進(jìn)行數(shù)據(jù)庫(kù)備份， 并且 RDB 恢復(fù)數(shù)據(jù)集的速度也要比 AOF 恢復(fù)的速度要快， 除此以外， 使用 RDB 還可以免之條件到的 AOF 程序的 bug 。