Redis持久化介紹

Redis是一個基于BSD開源許可的記憶體資料結構存儲系統，由于redis具有卓越的高并發讀寫特性，其主要用于用作資料庫、緩存和消息代理。redis具有内置的複制、lua、lru、事務和不同級别的磁盤持久性，并通過哨兵機制和叢集自動分區功能提供高可用性。本文主要介紹包含RDB（Redis DataBase）持久化、AOF（Append Only File）持久化、RDB和AOF混合持久化等持久化政策。

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 ""

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結尾。

• dir指定資料庫存放目錄為目前目錄

• 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檔案的内容壓縮。

作者：張文博

其他讨論

4大步驟節省30%浪費，優化企業上雲成本從了解雲開始！

運維思考 | 你知道CMDB與監控是什麼關系嗎？

【幹貨】4種Oracle DBaaS部署模式，你在使用哪一種？

如何改善監控問題，試試打造企業統一監控平台體系！

雲計算 | 資料在雲上安全嗎？DDoS攻擊怎麼辦？