摘要：主要是原因根據(jù)資料提示，可以能使由于如下原因文本協(xié)議的兼容性好前面我們提及到了文件是進行二進制加密，可能不同版本之間會出現(xiàn)不兼容的情況，采用文本協(xié)議可以加避免該問題。

為什么要做持久化存儲?

持久化存儲是將 Redis 存儲在內存中的數(shù)據(jù)存儲在硬盤中，實現(xiàn)數(shù)據(jù)的永久保存。我們都知道 Redis 是一個基于內存的 nosql 數(shù)據(jù)庫，內存存儲很容易造成數(shù)據(jù)的丟失，因為當服務器關機等一些異常情況都會導致存儲在內存中的數(shù)據(jù)丟失。

持久化存儲分類

在 Redis 中，持久化存儲分為兩種。一種是 aof 日志追加的方式，另外一種是 rdb 數(shù)據(jù)快照的方式。

RDB持久化存儲

什么是RDB持久化存儲

RDB持久化存儲即是將redis存在內存中的數(shù)據(jù)以快照的形式保存在本地磁盤中。

.RDB持久化存儲分為自動備份和手動備份

1.手動備份通過 save 命令和 bgsave 命令。save是同步阻塞，而 bgsave 是非阻塞(阻塞實際發(fā)生在 fork 的子進程中)。因此，在我們實際過程中大多是使用bgsave命令實現(xiàn)備份.

redis> SAVE
OK

redis> BGSAVE
Background saving started

2.自動備份
a.修改配置項 save m n即表示在 m 秒內執(zhí)行了 n 次命令則進行備份.
b.當Redis 從服務器項主服務器發(fā)送復制請求時，主服務器則會使用 bgsave命令生成 rbd 文件，然后傳輸給從服務器.
c.當執(zhí)行 debug reload 命令時也會使用 save 命令生成rdb文件.
d.當使用 shutdown 命令關掉服務時，如果沒有啟用 aof方式實現(xiàn)持久化則會采用bgsave的方式做持久化.同時shutdown后面可以加備份參數(shù)[nosave|save].

bgsave持久化存儲實現(xiàn)原理

1.執(zhí)行bgsave命令，Redis父進程判斷當前是否存在正在執(zhí)行的子進程，如果存在則直接返回.
2.父進程fork一個子進程(fork的過程中會造成阻塞的情況),這個過程可以使用info stats命令查看latest_fork_usec選項,查看最近一次fork操作小號的時間,單位是微妙.
3.父進程fork完之后,則會返回Background saving started信息提示,此時fork阻塞解除.
4.fork出的子進程開始根據(jù)父進程內存數(shù)據(jù)生成臨時的快照文件，然后替換原文件.使用lastsave命令可以查看最后一次生成rdb的時間，對應info的rdb_last_save_time選項.
5.當備份完畢之后向父進程發(fā)送完成信息，具體可以見info Persistence下的rbd_*選項.

RDB持久化的優(yōu)勢與劣勢

優(yōu)勢:
1.文件實現(xiàn)的數(shù)據(jù)快照，全量備份，便于數(shù)據(jù)的傳輸.比如我們需要把A服務器上的備份文件傳輸?shù)紹服務器上面，直接將rdb文件拷貝即可.
2.文件采用壓縮的二進制文件，當重啟服務時加載數(shù)據(jù)文件，比aof方式更快.
劣勢:
1.rbd采用加密的二進制格式存儲文件，由于Redis各個版本之間的兼容性問題也導致rdb由版本兼容問題導致無法再其他的Redis版本中使用.
2.時效性差，容易造成數(shù)據(jù)的不完整性.因為rdb并不是實時備份，當某個時間段Redis服務出現(xiàn)異常，內存數(shù)據(jù)丟失，這段時間的數(shù)據(jù)是無法恢復的，因此易導致數(shù)據(jù)的丟失.

RDB文件常見的處理方式

1.當遇到磁盤寫滿情況，可以使用如下命令來切換存儲磁盤

// dirName則是新的存儲目錄名(該方式同樣適用于aof格式)
config set dir dirName

2.文件壓縮處理，雖然對CPU具有消耗，但是減少體積的暫用，同時做文件傳輸(主從復制)也減少消耗.

// 修改壓縮開啟或關閉
config set rdbcompression yes|no

3.rbd備份文件損壞檢測.可以使用redis-check-rdb工具檢測rdb文件,該工具默認在/usr/local/bin/目錄下面.

[root@syncd redis-data]# /usr/local/bin/redis-check-rdb ./6379-rdb.rdb 
[offset 0] Checking RDB file ./6379-rdb.rdb
[offset 26] AUX FIELD redis-ver = "5.0.3"
[offset 40] AUX FIELD redis-bits = "64"
[offset 52] AUX FIELD ctime = "1552061947"
[offset 67] AUX FIELD used-mem = "852984"
[offset 83] AUX FIELD aof-preamble = "0"
[offset 85] Selecting DB ID 0
[offset 105] Checksum OK
[offset 105] o/ RDB looks OK! o/
[info] 1 keys read
[info] 0 expires
[info] 0 already expired

AOF持久化存儲

AOF持久化存儲是什么

AOF持久化存儲便是以日志的形式將redis存儲在aof_buf緩沖區(qū)中的數(shù)據(jù)寫入到磁盤中。簡而言之，就是記錄redis的操作日志，將redis執(zhí)行過的命令記錄下載，當我們需要數(shù)據(jù)恢復時，redis去重新執(zhí)行一次日志文件中的命令.

如何配置持久化存儲

// 將no改為yes，控制aof開啟與否
appendonly no
// 控制aof文件名稱，存儲的目錄便是dir配置項
appendfilename "appendonly.aof"
// 三種備份策略(三者只需要開啟以一個即可)
# appendfsync always // 命令寫入立即寫入磁盤
appendfsync everysec // 每秒實現(xiàn)文件的同步，寫入磁盤
# appendfsync no // 隨機進行文件的同步,同步操作則交給操作系統(tǒng)來負責，通常時間是最長30s

AOF持久化存儲實現(xiàn)原理

aof日志追加方式實現(xiàn)持久化存儲，需要經歷如下四個過程.命令寫入->文件同步->文件重寫->文件重載

1.redis命令寫入，此時會將redis命令寫入aof_buf換從區(qū).
2.緩沖區(qū)中數(shù)據(jù)根據(jù)備份策略實現(xiàn)寫入日志文件.
3.當aof的文件越來越龐大，會根據(jù)我們的配置策略來實現(xiàn)aof的重寫，實現(xiàn)文件的壓縮，減少體積.
4.當redis重新啟動時，在去重寫加載aof文件，達到數(shù)據(jù)恢復的目的.

命令寫入

命令寫入主要是將文件執(zhí)行過的命令寫入到日志文件中.并且日志文件尊徐文本協(xié)議格式，下面示例代碼便是aof日志文件中存儲的內容格式.

*3
$3
set
$5
hello
$5
world

aof采用的是文本協(xié)議格式。主要是原因根據(jù)資料提示，可以能使由于如下原因.
1.文本協(xié)議的兼容性好.前面我們提及到了rdb文件是進行二進制加密，可能不同版本之間會出現(xiàn)不兼容的情況，采用文本協(xié)議可以加避免該問題。同時文本協(xié)議也可以減少跨平臺使用所帶來的諸多問題.
2.可讀性強.由于aof是將命令寫入文件中，我們可以直接查看命令內容，同時也可以修改日志文件內容.
3.開啟aof后，所有的文件文件都包含追加操作，直接采用文本協(xié)議，減少二次開銷(這一點，個人不是很理解.因為我們的aof是保存的是命令，當我們再次去加載的時候，會去執(zhí)行一次里面的命令，當文件大的時候應該是比較耗時的吧。如果沒有做好文件重寫策略，大量重復無效的命令執(zhí)行，對于二進制加密的rdb格式，不需要再去轉換，這一點確實可以減少二次開銷).

文件寫入

文件寫入是將aof_buf緩沖區(qū)的命令寫入到文件中.文件寫入的策略有如下三種方式

系統(tǒng)調用write和fsync說明：
·write操作會觸發(fā)延遲寫（ delayed write） 機制。 Linux在內核提供頁緩沖區(qū)用來提高硬盤IO性能。 write操作在寫入系統(tǒng)緩沖區(qū)后直接返回。 同步硬盤操作依賴于系統(tǒng)調度機制， 例如： 緩沖區(qū)頁空間寫滿或達到特定時間周期。 同步文件之前， 如果此時系統(tǒng)故障宕機， 緩沖區(qū)內數(shù)據(jù)將丟失.
·fsync針對單個文件操作（ 比如AOF文件） ， 做強制硬盤同步， fsync將阻塞直到寫入硬盤完成后返回， 保證了數(shù)據(jù)持久化.
文件寫入策略分析
配置為always時， 每次寫入都要同步AOF文件， 在一般的SATA硬盤上， Redis只能支持大約幾百TPS寫入， 顯然跟Redis高性能特性背道而馳，
不建議配置.
配置為no。由于操作系統(tǒng)每次同步AOF文件的周期不可控， 而且會加大每次同步硬盤的數(shù)據(jù)量， 雖然提升了性能， 但數(shù)據(jù)安全性無法保證.
配置為everysec。是建議的同步策略， 也是默認配置， 做到兼顧性能和數(shù)據(jù)安全性。 理論上只有在系統(tǒng)突然宕機的情況下丟失1秒的數(shù)據(jù).

文件重載

1.為什么要文件做文件重載操作?
由于aof采用的是日志追加，我們redis命令不斷的寫入，aof文件的體積也也會不斷的增加.因此redis引入了aof重寫機制達到減小aof文件體積.aof文件重寫是把redis進程內的數(shù)據(jù)轉換為寫命令同步到新的aof文件的過程(這一點其實不是特別明白，文件重寫不是針對aof文件文件做操作的嗎？為什么這里是將redis進程內的數(shù)據(jù)轉換為命令寫入文件，這里的進程內的數(shù)據(jù)不是太明白，還有待深入研究.個人理解的就是將舊的aof文件內容根據(jù)重寫策略，進行優(yōu)化生成新的aof文件。).
2.文件重載有什么好處?
文件重載主要優(yōu)化的地方有如下三點。使用文件重載既可以減少文件的體積，同時去掉了一些無效的操作，可以加快文件重載效率.
a.將一些在進程內無效的數(shù)據(jù)不在寫入新的文件.如過期的鍵.
b.去掉一些無效的命令.如del key1.
c.簡化操作.如lpush list a,lpush list b.直接可以簡化為lpush list a b.
3.文件重載由那些方式?
文件重載有自動觸發(fā)機制和手動觸發(fā)機制.
手動觸發(fā)機制:直接使用bgrewriteaof命令即可.該命令在fork子進程的時候會發(fā)生阻塞.
自動觸發(fā)機制:
auto-aof-rewrite-min-size:aof重寫時文件最小的體積，默認的是64M.
auto-aof-rewrite-percentage:代表當前AOF文件空間（ aof_current_size） 和上一次重寫后AOF文件空間（ aof_base_size） 的比值.

自動觸發(fā)時機=aof_current_size>auto-aof-rewrite-minsize&&（ aof_current_size-aof_base_size） /aof_base_size>=auto-aof-rewritepercentage

其中aof_current_size和aof_base_size可以在info Persistence統(tǒng)計信息中查看.
4.文件重載實現(xiàn)的原理是怎樣的?

1.執(zhí)行重寫命令，判斷是否存在子進程。
如果已經有子進程在進行aof重寫，則會提示如下信息.

ERR Background append only file rewriting already in progress

如果已經存在子進程在進行bgsave操作，重寫命令會延遲到bgsave命令完成之后進行，會返回如下信息.

Background append only file rewriting scheduled

2.父進程會fork一個子進程，在fork子進程的過程中會造成阻塞.
3.fork子進程結束阻塞解除，進行其他新的命令操作.新的命令依舊根據(jù)文件寫入策略同步數(shù)據(jù),保證aof機制正確進行(圖中3.1).
4.子進程在進行寫的過程中，由于fork操作運用的是寫時復制技術，子進程只能共享fork操作時內存保留的數(shù)據(jù)，新的數(shù)據(jù)是無法操作的.父進程在這過程中仍然在響應其他的命令，于是Redis會使用aof重寫緩存區(qū)來保存這部分新的數(shù)據(jù)(圖中3.2).
5.子進程進行根據(jù)重寫規(guī)則將數(shù)據(jù)寫入到新的aof文件中，并且每次寫入有大小限制,通過aof-rewrite-incremental-fsync配置項來控制，默認是32M,這樣可以見減少單次刷盤(I/O寫)造成硬盤阻塞.
6.子進程在完成重寫之后，會向父進程發(fā)送信息，父進程更新統(tǒng)計信息.可參看info persistence下的aof_*相關統(tǒng)計。
7.父進程會把新寫入存在aof重寫緩沖區(qū)的數(shù)據(jù)寫入到aof文件中(圖5.2).
8.將新的aof文件替換掉舊的aof文件.
在第3和4中，其實不是特別理解.不理解的是為什么父進程在響應新的命令會寫入舊的aof文件，還要aof重寫緩存區(qū).個人理解的是，父進程在進行新命令寫入處理的策略是，按照正常的備份策略寫入舊的aof的同時也把新的命令寫入重寫緩沖區(qū)，在第5.2中將這部分新的數(shù)據(jù)寫入到新的aof文件中,這樣保證數(shù)據(jù)的完整性.

文件重載

文件重載就是將文件重新加入到redis服務中.比如redis服務重啟用于數(shù)據(jù)恢復.redis的重載機制非常完善，具體流程如下.

AOF文件常見的問題處理

1.文件損壞
我們在加載損壞的文件是可能提示如下信息.

Bad file format reading the append only file: make a backup of your AOF file,then use ./redis-check-aof --fix 

此時我們可以使用redis-check-aof --fix命令進行修復(記得對文件做個備份).修復后使用diff-u進行數(shù)據(jù)對比，找出部分丟失的數(shù)據(jù).
2.文件加載不完整
這可能是數(shù)據(jù)在備份的時候，redis服務異常，導致備份不完整.可以使用redis的aof-load-truncated兼容該異常

AOF的優(yōu)缺點

優(yōu)點:
多種文件寫入(fsync)策略.
數(shù)據(jù)實時保存，數(shù)據(jù)完整性強.即使丟失某些數(shù)據(jù)，制定好策略最多也是一秒內的數(shù)據(jù)丟失.
可讀性強，由于使用的是文本協(xié)議格式來存儲的數(shù)據(jù),可有直接查看操作的命令，同時也可以手動改寫命令.
缺點:
文件體積過大，加載速度比rbd慢.由于aof記錄的是redis操作的日志,一些無效的，可簡化的操作也會被記錄下來,造成aof文件過大.但該方式可以通過文件重寫策略進行優(yōu)化.

選擇AOF還是RDB進行數(shù)據(jù)的持久化

1.針對不同的情況來選擇，建議使用兩種方式相結合.
2.針對數(shù)據(jù)安全性、完整性要求高的采用aof方式.
3.針對不太重要的數(shù)據(jù)可以使用rdb方式.
4.對于數(shù)據(jù)進行全量備份，便于數(shù)據(jù)備份的可以采用rdb方式.
原文轉自微信公眾號:浪子編程走四方