RDB(Redis Database)

在指定的時間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫入磁盤， 也就是行話講的Snapshot快照，它恢復(fù)時是將快照文件直接讀到內(nèi)存里。

RDB過程說明

• Redis會單獨創(chuàng)建（fork）一個子進程來進行持久化，會先將數(shù)據(jù)寫入到 一個臨時文件中，待持久化過程都結(jié)束了，再用這個臨時文件替換上次持久化好的文件。 整個過程中，主進程是不進行任何IO操作的，這就確保了極高的性能

RDB特性

有點

• RDB 在保存RDB文件時父進程唯一需要做的就是創(chuàng)建（fork）一個子進程，接下來的工作全部由子進程去完成。父進程不需要做其他的IO操作。所以RDB持久化方式可以最大化redis的性能。
• 如果需要進行大規(guī)模數(shù)據(jù)的恢復(fù)，且對于數(shù)據(jù)恢復(fù)的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺點是最后一次持久化后的數(shù)據(jù)可能丟失。

缺點

• 數(shù)據(jù)丟失風險大，在一定間隔時間做一次備份，所以如果redis意外down掉的話，就 會丟失最后一次快照后的所有修改；
• RDB需要經(jīng)常fork子進程來保存數(shù)據(jù)集到硬盤，當數(shù)據(jù)集比較大的時候，fork的過程是非常耗時的，可能會導(dǎo)致redis在一些毫秒級不能影響客戶端請求。fork的時候，內(nèi)存中的數(shù)據(jù)被克隆了一份，大致2倍的膨脹性需要考慮；
  fork的作用是復(fù)制一個與當前進程一樣的進程。新進程的所有數(shù)據(jù)（變量、環(huán)境變量、程序計數(shù)器等） 數(shù)值都和原進程一致，但是是一個全新的進程，并作為原進程的子進程。

如何觸發(fā)RDB

1. 配置文件中默認的快照配置，冷拷貝后重新使用，可以cp dump.rdb dump_new.rdb。然后要還原數(shù)據(jù)的時候就將dump_new.rdb還原成dump.rdb，然后重新啟動的時候就會自動加載。
2. 命令save或者是bgsave，這個會強制的備份。

*   `Save`：save時**只管保存**，其它不管，全部阻塞。
*   `BGSAVE`：Redis會在后臺異步進行快照操作， 快照同時還可以響應(yīng)客戶端請求?？梢酝ㄟ^lastsave 命令獲取最后一次成功執(zhí)行快照的時間。
*   執(zhí)行flushall命令，也會產(chǎn)生`dump.rdb`文件，但里面是空的，無意義 (**當時還挖了一個坑**)。
* 即: 調(diào)用`save`也就是立刻、馬上備份。`flushAll`也可以馬上形成備份，但是沒有意義。

RDB的配置:

redis.conf相關(guān)文件關(guān)于 RDB的配置:

• save配置：RDB是整個內(nèi)存的壓縮過的Snapshot，RDB的數(shù)據(jù)結(jié)構(gòu)，可以配置復(fù)合的快照觸發(fā)條件。默認是1分鐘內(nèi)改了1次，或5分鐘內(nèi)改了10次，或15分鐘內(nèi)改了1次。
• stop-writes-on-bgsave-error : 如果配置成no，表示你不在乎數(shù)據(jù)不一致或者有其他的手段發(fā)現(xiàn)和控制。
• rdbcompression ：rdbcompression：對于存儲到磁盤中的快照，可以設(shè)置是否進行壓縮存儲。如果是的話，redis會采用LZF算法進行壓縮。如果你不想消耗CPU來進行壓縮的話，可以設(shè)置為關(guān)閉此功能。
• dbfilename: 默認是dump.rdb。
• dir: 生成dump.rdb的默認目錄。

如何恢復(fù)

將備份文件 (dump.rdb) 移動到 redis 安裝目錄并啟動服務(wù)即可。
獲取目錄
redis-cli config get dir

如何停止

動態(tài)所有停止RDB保存規(guī)則的方法：redis-cli config set save ""

AOF(Append Only File)

以日志的形式來記錄每個寫操作；
將Redis執(zhí)行過的所有寫指令記錄下來(讀操作不記錄)， 只許追加文件但不可以改寫文件，redis啟動之初會讀取該文件重新構(gòu)建數(shù)據(jù)，換言之，redis 重啟的話就根據(jù)日志文件的內(nèi)容將寫指令從前到后執(zhí)行一次以完成數(shù)據(jù)的恢復(fù)工作。

概念: AOF采用文件追加方式，文件會越來越大為避免出現(xiàn)此種情況，新增了重寫機制, 當AOF文件的大小超過所設(shè)定的閾值時，Redis就會啟動AOF文件的內(nèi)容壓縮， 只保留可以恢復(fù)數(shù)據(jù)的最小指令集.可以使用命令bgrewriteaof。

AOF文件持續(xù)增長而過大時，會fork出一條新進程來將文件重寫(也是先寫臨時文件最后再rename)， 遍歷新進程的內(nèi)存中數(shù)據(jù)，每條記錄有一條的Set語句。重寫aof文件的操作，并沒有讀取舊的aof文件， 而是將整個內(nèi)存中的數(shù)據(jù)庫內(nèi)容用命令的方式重寫了一個新的aof文件，這點和快照有點類似。

AOF配置

• appendonly，默認是no，我們要改成yes才會有作用；
• appendfilename，默認是appendonly.aof；
• appendfsync: always(同步持久化 每次發(fā)生數(shù)據(jù)變更會被立即記錄到磁盤 性能較差但數(shù)據(jù)完整性比較好)。everysec(出廠默認推薦，異步操作，每秒記錄 如果一秒內(nèi)宕機，有數(shù)據(jù)丟失)，no。
  觸發(fā)機制:
  Redis會記錄上次重寫時的AOF大小，默認配置是當AOF文件大小是上次rewrite后大小的一倍且文件大于64M時觸發(fā)。

優(yōu)勢和劣勢

優(yōu)勢:

• 每修改同步：appendfsync always 同步持久化 每次發(fā)生數(shù)據(jù)變更會被立即記錄到磁盤 性能較差但數(shù)據(jù)完整性比較好。
• 每秒同步：appendfsync everysec 異步操作，每秒記錄 如果一秒內(nèi)宕機，有數(shù)據(jù)丟失。
• 不同步：appendfsync no 從不同步。
  劣勢:
• 相同數(shù)據(jù)集的數(shù)據(jù)而言aof文件要遠大于rdb文件，恢復(fù)速度慢于rdb；
• aof運行效率要慢于rdb，每秒同步策略效率較好，不同步效率和rdb相同；

RDB和AOF對比和選擇

• RDB持久化方式能夠在指定的時間間隔能對你的數(shù)據(jù)進行快照存儲。
• AOF持久化方式記錄每次對服務(wù)器寫的操作,當服務(wù)器重啟的時候會重新執(zhí)行這些 命令來恢復(fù)原始的數(shù)據(jù),AOF命令以redis協(xié)議追加保存每次寫的操作到文件末尾. Redis還能對AOF文件進行后臺重寫,使得AOF文件的體積不至于過大。
• 只做緩存：如果你只希望你的數(shù)據(jù)在服務(wù)器運行的時候存在,你也可以不使用任何持久化方式。
• 同時開啟:
• 在這種情況下,當redis重啟的時候會優(yōu)先載入AOF文件來恢復(fù)原始的數(shù)據(jù), 因為在通常情況下AOF文件保存的數(shù)據(jù)集要比RDB文件保存的數(shù)據(jù)集要完整。
• RDB的數(shù)據(jù)不實時，同時使用兩者時服務(wù)器重啟也只會找AOF文件。那要不要只使用AOF呢？ 作者建議不要，因為RDB更適合用于備份數(shù)據(jù)庫(AOF在不斷變化不好備份)， 快速重啟，而且不會有AOF可能潛在的bug，留著作為一個萬一的手段。

性能建議：

• 因為RDB文件只用作后備用途，建議只在Slave上持久化RDB文件，而且只要15分鐘備份一次就夠了，只保留save 900 1這條規(guī)則。
• 如果Enalbe AOF，好處是在最惡劣情況下也只會丟失不超過兩秒數(shù)據(jù)，啟動腳本較簡單只load自己的AOF文件就可以了。代價一是帶來了持續(xù)的IO，二是AOF rewrite的最后將rewrite過程中產(chǎn)生的新數(shù)據(jù)寫到新文件造成的阻塞幾乎是不可避免的。只要硬盤許可，應(yīng)該盡量減少AOF rewrite的頻率，AOF重寫的基礎(chǔ)大小默認值64M太小了，可以設(shè)到5G以上。默認超過原大小100%大小時重寫可以改到適當?shù)臄?shù)值。
• 如果不Enable AOF ，僅靠Master-Slave Replication 實現(xiàn)高可用性也可以。能省掉一大筆IO也減少了rewrite時帶來的系統(tǒng)波動。代價是如果Master/Slave同時倒掉，會丟失十幾分鐘的數(shù)據(jù)，啟動腳本也要比較兩個Master/Slave中的RDB文件，載入較新的那個。新浪微博就選用了這種架構(gòu)。