Redis是一個基於BSD開源許可的內存數據結構存儲系統，因爲redis具備卓越的高併發讀寫特性，其主要用於用做數據庫、緩存和消息代理。redis具備內置的複製、lua、lru、事務和不一樣級別的磁盤持久性，並經過哨兵機制和集羣自動分區功能提供高可用性。本文主要介紹包含RDB（Redis DataBase）持久化、AOF（Append Only File）持久化、RDB和AOF混合持久化等持久化策略。redis

Redis如下幾種持久性選項範圍：數據庫

RDB持久性按指定的時間間隔執行數據集的時間點快照。

AOF持久性會記錄服務器接收的每一個寫入操做，這些操做將在服務器啓動時再次播放，以重建原始數據集。使用與Redis協議自己相同的格式記錄命令，而且採用僅追加方式。當日志太大時，Redis能夠在後臺重寫日誌。

能夠在同一實例中同時合併AOF和RDB。在這種狀況下，當Redis從新啓動時，AOF文件將用於重建原始數據集，由於它能夠保證是最完整的。

若是但願只用做緩存服務器，對數據的持久性無要求，也能夠徹底禁用持久性。

下面着重介紹RDB和AOF持久化的特色和應用場景。緩存

RDB持久化

RDB持久化的優勢

RDB 是 Redis 默認的持久化方案。在指定的時間間隔內，寫操做達到指定的次數，則會將內存中的數據寫入到磁盤RDB文件中。因爲RDB文件是一個很是緊湊的文件，比較容易備份，因此RDB對於災難恢復很是有用。RDB最大限度地提升了Redis的性能，由於Redis父進程的持久化操做是經過分叉子進程實現，而父進程不會執行磁盤I / O等操做。與AOF相比，RDB容許大型數據集更快地重啓。安全

RDB持久化的缺點

RDB持久化的寫入方式決定了該持久化策略並不能徹底保證數據的安全性。RDB須要常用fork（）才能使用子進程將其持久化在磁盤上。若是數據集很大，Fork（）可能很耗時，而且若是數據集很大且CPU性能不佳，則可能致使Redis中止爲客戶端服務幾毫秒甚至一秒鐘。該過程若是出現宕機，則可能形成數據丟失。服務器

RDB持久化配置

打開 redis.conf 文件，定位到 SNAPSHOTTING 對應內容數據結構

save <seconds> <changes>併發

# save ""app

save 900 1運維

save 300 10高併發

save 60 10000

dbfilename dump.rdb

dir ./

rdbcompression yes

save <指定時間間隔> <執行指定次數更新操做>，知足條件就將內存中的數據同步到硬盤中。官方出廠配置默認是 900秒內有1個更改，300秒內有10個更改以及60秒內有10000個更改，則將內存中的數據快照寫入磁盤。關閉RDB，則把上面配置註釋便可。

dbfilename指定本地數據庫文件名，默認文件名爲 dump.rdb，文件格式.rdb結尾。

rdbcompression開啓數據壓縮，默認爲yes，Redis採用LZF壓縮方式。

RDB的觸發與恢復

觸發RDB快照的方式有save策略觸發，flush命令（清空數據庫全部數據），shutdown（關閉redis）命令，三種方式都是調用redis的bgsave機制實現快照觸發。

RDB文件恢復數據的方式是將dump.rdb 文件拷貝到redis的安裝目錄的bin目錄下，重啓redis服務便可。

AOF持久化

AOF持久化的優點

AOF能夠彌補RDB的不足（數據的不一致性），它採用日誌的形式來記錄每一個寫操做，並追加到文件中。Redis 重啓的會根據日誌文件的內容將寫指令從前到後執行一次以完成數據的恢復工做。

使用AOF Redis更加持久，提供不一樣的fsync策略：徹底沒有fsync，每秒fsync，每一個查詢fsync。使用默認策略fsync時，每秒的寫入性能仍然很好（fsync是使用後臺線程執行的，而且在沒有進行fsync的狀況下，主線程將盡力執行寫入操做。）

AOF日誌是僅追加的日誌，所以即使是斷電故障，也不會出現磁盤尋道或損壞問題。即便因爲某種緣由（磁盤已滿或其餘）致使日誌錯誤，也可使用redis-check-aof工具=輕鬆修復。

AOF持久化的缺點

對於同一數據集，AOF文件一般大於等效的RDB文件。在特定的fsync策略下，AOF比RDB的效率低。一般，在將fsync設置爲每秒的狀況下，性能仍然很高，而且在禁用fsync的狀況下，即便在高負載下，它也應與RDB同樣快。即便在巨大的寫負載的狀況下，RDB仍然可以提供有關最大延遲的更多保證。可是若是fsync策略爲aways，則隨着集羣負載增大，AOF記錄的內容愈來愈大多，文件會愈來愈大，數據恢復也會愈來愈慢。

AOF持久化配置

打開 redis.conf 文件，定位到APPEND ONLY MODE 對應內容

appendonly yes

appendfilename "appendonly.aof"

appendfsync everysec

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

說明：

appendonly 配置redis 默認關閉，開啓須要手動把no改成yes
appendfilename指定本地數據庫文件名，默認值爲 appendonly.aof
appendfsync everysec指定更新日誌條件爲每秒更新，共三種策略（aways，everyse，no）
auto-aof-rewrite-min-size配置重寫觸發機制，當AOF文件大小是上次rewrite後大小的一倍且文件大於64M時觸發。

AOF觸發與恢復

AOF主要根據配置文件策略觸發，能夠是每次執行觸發，能夠是每秒觸發，能夠不一樣步。

AOF的恢復主要是將appendonly.aof 文件拷貝到redis的安裝目錄的bin目錄下，重啓redis服務便可。但在實際開發中，可能由於某些緣由致使appendonly.aof 文件異常，從而致使數據還原失敗，能夠經過命令redis-check-aof --fix appendonly.aof 進行修復

AOF的工做原理是將寫操做追加到文件中，文件的冗餘內容會愈來愈多。因此Redis 新增了重寫機制，經過auto-aof-rewrite-min-size控制。當AOF文件的大小超過所設定的閾值時，Redis就會對AOF文件的內容壓縮。

做者：張文博