![](https://img.laitimes.com/img/__Qf2AjLwojIjJCLyojI0JCLiAjM2EzLcd3LcJzLcJzdllmVldWYtl2PnVGcq5iayhzM5IjdnlTbvwVM3czN1QTNtUGall3LcVmdhNXLwRHdo9CXt92YucWbpRWdvx2Yx5yazF2Lc9CX6MHc0RHaiojIsJye.jpeg)
介紹
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 | |
---|---|---|
持久化方式 | 生成某一時刻快照檔案 | 實時記錄寫指令到日志 |
資料完整性 | 不完整,取決于備份周期 | 完整性相對較高,取決于刷盤機制 |
檔案大小 | 二進制檔案,相對較小 | 儲存原始指令,檔案較大 |
當機恢複時間 | 快 | 慢 |
使用場景 | 當機需要快速恢複,允許一定數量的資料丢失 | 對資料可靠性要求較高 |
有幫助?在看來一波