介紹
Redis中的數據存在內存中，如果突然宕機，那麼內存中的數據將全部丟失。如果數據能從後端數據庫恢復還好，如果數據只存在Redis中，那數據就全丟失了。並且如果請求量很多，MySQL服務器的壓力會很大。
所以最好的方式是對數據進行持久化，並能當宕機的時候能快速恢復
「在Redis中有如下兩種持久化方式，rdb快照和aof日誌」
RDB
rdb就是對當前數據庫的狀態做一個快照，將某個階段的數據通過二進制文件保存下來。你可以類比照相。內存中的數據越多，生成快照的時候就越長，同時將快照寫入磁盤耗費的時間也越長。
「這時我們不經要問，生成快照會阻塞主線程嗎？」 如果會阻塞主線程，則會影響正常請求的處理
在Redis中有兩個命令可以用於生成RDB文件，一個是save，另一個是bgsave
-
save：在主線程中執行，會導致阻塞 -
bgsave：主線程fork出一個子進程負責創建rdb文件，不會阻塞主線程
我們當然毫不猶豫的選擇bgsave，畢竟不會阻塞主線程
「那當我們使用bgsave時生成鏡像的時候數據還能被修改嗎？」
如果數據允許被修改，會有很多問題。例如，bgsave子進程剛持久化完一個key，結果主線程就把這個key給刪了，會造成數據不一致。
如果數據不允許被修改，那麼所有寫操作只能等到rdb文件生成完才能執行，影響性能。
「這時我們就不得不提到COW了，redis是使用多進程COW機制來實現快照持久化的」
Copy-On-Write，COW
Redis在進行持久化的時候，會fork出一個子進程，快照持久化交給子進程來完成。子進程剛剛產生的時候，它和父進程共享裏面的數據段和代碼段。所以在進程分離的一瞬間，內存的增長機會沒有變化。
子進程做持久化，不會修改內存中的數據，但是主線程不一樣，它會持久接收客戶端的修改請求，然後修改內存中的數據。
這時就會使用操作系統的COW機制來進行數據段頁面的分離。數據段由很多操作系統的頁面組成，當父進程對其中一個頁面的數據進行修改時，會將被共享的頁面複製一份分離出來，然後對這個複製的頁面進行修改。這時子進程相應的頁面是沒有變化的，還是進程產生時的數據。
隨着父進程修改操作的進行，越來越多共享的頁面被分離出來，頁面就會持續增長，但是不超過原有內存的2倍。
「子進程中的數據一直沒有變化，它就可以安心的做持久化了。」
如果每隔1分鐘生成一個快照，宕機後還是會丟失快照生成後所執行的操作（最多爲1分鐘之內的操作）。我們把生成快照的時間縮短，又會影響Redis性能，畢竟fork子進程會阻塞主線程，頻繁讀寫磁盤，也會給磁盤帶來很大壓力。
這是就不得不提到另一種持久化的方式，aof日誌
AOF
當我們每次執行一條命令的時候，把對應的操作記到aof日誌中，當redis宕機的時候我們只要重放日誌就能恢復數據。而且Redis是以文本的形式保存aof日誌的
例如當我們執行如下一條命令
set key value
aof文件中就會追加如下的內容
*3
$3
set
$3
key
$5
value
*3表示當前命令有3個部分，每部分都是由“$+數字開頭”，數字表示命令，鍵或者值由幾個字節組成
需要注意的是，「redis中記錄的是寫後日志」，即先執行命令，再寫日誌。那要是命令執行成功，還沒有來得及寫日誌？那麼服務宕機後這條命令不是丟失了？因爲aof日誌是在主線程中寫入的，如果每次寫日誌都刷到磁盤，豈不是很影響性能？
好在redis給我們提供了三種寫aof日誌的方式
「always」：同步寫回，寫命令執行完就同步到磁盤
「everysec」：每秒寫回，每個寫命令執行完，只是先把日誌寫到aof文件的內存緩衝區，每隔1秒將緩衝區的內容寫入磁盤
「no」：操作系統控制寫回，每個寫命令執行完，只是先把日誌寫到aof文件的內存緩衝區，由操作系統決定何時將緩衝區內容寫回到磁盤
當aof的刷盤機制爲always，redis每處理一次寫命令，都會把寫命令刷到磁盤中才返回，整個過程是在Redis主線程中進行的，勢必會拖慢redis的性能
當aof的刷盤機制爲everysec，redis寫完內存後就返回，刷盤操作是放到後臺線程中去執行的，後臺線程每隔1秒把內存中的數據刷到磁盤中
當aof的刷盤機制爲no，宕機後可能會造成部分數據丟失，一般不採用。
「一般情況下，aof刷盤機制配置爲everysec即可」
aof日誌是通過保存被執行的寫命令來記錄數據庫狀態的，隨着時間的流逝，aof日誌會越來越大，使用aof文件來還原數據所需要的時間也越來越長。有沒有什麼優化方案呢？此時aof日誌重寫登場了。
AOF日誌重寫
假如說客戶端依次執行了如下5條命令
127.0.0.1:6379> rpush list 1
(integer) 1 // [1]
127.0.0.1:6379> rpush list 2
(integer) 2 // [1, 2]
127.0.0.1:6379> rpush list 3
(integer) 3 // [1, 2, 3]
127.0.0.1:6379> lpop list
"1" // [2, 3]
127.0.0.1:6379> rpush list 1
(integer) 3 // [2, 3, 1]
單獨記list這個key的狀態就得有5條日誌。要是能把這5條命令合併成 rpush list 2 3 1這個命令就好了。其實這就是aof日誌重寫要乾的事情，那麼如何實現呢？
雖然Redis將生成新的aof文件的功能命名爲"aof重寫"，但是aof重寫並不需要對現有aof文件進行任何讀取，分析操作。而是直接讀取讀取內存中的最新值，然後保存對應的命令。
例如上面的例子，redis直接讀取list的值，並生成一條rpush list 2 3 1命令放到aof日誌中。
「可以看到aof重寫是一個非常耗時的操作，那麼它會阻塞主線程嗎？」
不會，因爲作爲一種優化手段，Redis肯定不希望它被阻塞。所以每次重寫的時候主線程fork出一個bgrewriteaof子進程。bgrewriteaof子進程使用Copy-On-Write技術來讀取內存中的數據，寫新的aof日誌
「那在重寫aof日誌的過程中，主線程執行的操作該怎麼寫到新的aof日誌中？」
其實在aof日誌重寫的過程中，主線程會把操作同步到aof緩衝區和aof重寫緩衝區。當子線程完成aof重寫，並且將aof重寫緩衝區的內容，寫入新的aof日誌中時，就會用新的aof日誌代替舊的aof日誌
「Redis生成rdb文件和aof日誌重寫，都是通過主線程fork子進程的方式，讓子進程來執行的」
Redis4.0混合持久化
「當使用RDB做持久化時，宕機後會造成一部分數據的丟失」，此時可以縮短生成RDB快照的時間間隔，但是如果頻繁的生成RDB快照，有會有如下兩方面的問題
-
頻繁的將全量數據寫到磁盤，會給磁盤造成很大的壓力 -
主線程fork子進程來生成rdb快照，子進程生成rdb快照不會阻塞主線程，但是主線程通過fork創建子進程的過程會阻塞主線程，主線程的內存越大，阻塞時間越長。
「當使用AOF做持久化的時候，數據完整性較高，但是宕機後恢復時間比較長。」
那有沒有什麼方法？即能做到快速恢復，又能保證數據完整性較高？
你別說，還真有。Redis4.0提出了一種混合持久化的方式。就是快照按照一定的頻率執行，在2次快照之間，用aof日誌記錄這個期間所有的命令操作。當第2次快照生成的時候可以清空aof文件，因爲此時命令已經記錄到快照中了。
在Redis重啓的時候，可以先加載rdb文件的內容，然後重放aof日誌即可。
區別
| rdb | aof | |
|---|---|---|
| 持久化方式 | 生成某一時刻快照文件 | 實時記錄寫命令到日誌 |
| 數據完整性 | 不完整，取決於備份週期 | 完整性相對較高，取決於刷盤機制 |
| 文件大小 | 二進制文件，相對較小 | 保存原始命令，文件較大 |
| 宕機恢復時間 | 快 | 慢 |
| 使用場景 | 宕機需要快速恢復，允許一定數量的數據丟失 | 對數據可靠性要求較高 |
有幫助？在看來一波
本文分享自微信公衆號 - Java識堂（erlieStar）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。