一文詳解Redis中的持久化
1. 前言
為什么要進(jìn)行持久化?:持久化功能有效地避免因進(jìn)程退出造成的數(shù)據(jù)丟失問題,當(dāng)下次重啟時利用之前持久化的文件即可實現(xiàn)數(shù)據(jù)恢復(fù)。
持久化都有那些方式?:Redis支持RDB和AOF兩種持久化機(jī)制。
2. RDB
RDB持久化是把當(dāng)前進(jìn)程數(shù)據(jù)生成快照保存到硬盤的過程,觸發(fā)RDB持久化過程分為手動觸發(fā)和自動觸發(fā)。
2.1 手動觸發(fā)
手動觸發(fā)分別對應(yīng)save
和bgsave
命令:
save
命令::阻塞當(dāng)前Redis服務(wù)器,直到RDB過程完成為止,對于內(nèi)存比較大的實例會造成長時間阻塞,線上環(huán)境不建議使用。bgsave
命令:Redis進(jìn)程執(zhí)行fork操作創(chuàng)建子進(jìn)程,RDB持久化過程由子進(jìn)程負(fù)責(zé),完成后自動結(jié)束。阻塞只發(fā)生在fork階段,一般時間很短。
顯然bgsave命令是針對save阻塞問題做的優(yōu)化。因此Redis內(nèi)部所有的涉及RDB的操作都采用bgsave的方式,而save命令已經(jīng)廢棄。
2.2 自動觸發(fā)
- 使用save相關(guān)配置,如
save m n
。表示m秒內(nèi)數(shù)據(jù)集存在n次修改時,自動觸發(fā)bgsave。 - 如果從節(jié)點執(zhí)行全量復(fù)制操作,主節(jié)點自動執(zhí)行bgsave生成RDB文件并發(fā)送給從節(jié)點。
- 執(zhí)行debug reload命令重新加載Redis時,也會自動觸發(fā)save操作。
- 默認(rèn)情況下執(zhí)行shutdown命令時,如果沒有開啟AOF持久化功能則自動執(zhí)行bgsave。
3. bgsave大致流程
流程說明:
- 執(zhí)行bgsave命令,Redis父進(jìn)程判斷當(dāng)前是否存在正在執(zhí)行的子進(jìn)程,如RDB/AOF子進(jìn)程,如果存在bgsave命令直接返回。
- 父進(jìn)程執(zhí)行fork操作創(chuàng)建子進(jìn)程,fork操作過程中父進(jìn)程會阻塞,通過
info stats
命令查看latest_fork_usec選項,可以獲取最近一個fork操作的耗時,單位為微秒。 - 父進(jìn)程fork完成后,bgsave命令返回“Background saving started”信息并不再阻塞父進(jìn)程,可以繼續(xù)響應(yīng)其他命令。
- 子進(jìn)程創(chuàng)建RDB文件,根據(jù)父進(jìn)程內(nèi)存生成臨時快照文件,完成后對原有文件進(jìn)行原子替換。執(zhí)行
lastsave
命令可以獲取最后一次生成RDB的時間,對應(yīng)info統(tǒng)計的rdb_last_save_time選項。 - 進(jìn)程發(fā)送信號給父進(jìn)程表示完成,父進(jìn)程更新統(tǒng)計信息,具體見info Persistence下的rdb_*相關(guān)選項。
關(guān)于RDB文件:
- 存儲位置:RDB文件保存在dir配置指定的目錄下,文件名通過dbfilename配置指定??梢酝ㄟ^執(zhí)行config set dir{newDir}和config set dbfilename{newFileName}運行期動態(tài)執(zhí)行,當(dāng)下次運行時RDB文件會保存到新目錄。
- 壓縮:Redis默認(rèn)采用LZF算法對生成的RDB文件做壓縮處理,壓縮后的文件遠(yuǎn)遠(yuǎn)小于內(nèi)存大小,默認(rèn)開啟,可以通過參數(shù)config set rdbcompression{yes|no}動態(tài)修改。
- 校驗:如果Redis加載損壞的RDB文件時拒絕啟動,并打印
# Short read or OOM loading DB. Unrecoverable error, aborting now.
(可以使用Redis提供的redis-check-dump工具檢測RDB文件并獲取對應(yīng)的錯誤報告)。
4. RDB持久化方式的優(yōu)缺點
優(yōu)點:
- RDB是一個緊湊壓縮的二進(jìn)制文件,代表Redis在某個時間點上的數(shù)據(jù)快照。非常適用于備份,全量復(fù)制等場景。比如每6小時執(zhí)行bgsave備份,并把RDB文件拷貝到遠(yuǎn)程機(jī)器或者文件系統(tǒng)中(如hdfs),用于災(zāi)難恢復(fù)。(數(shù)據(jù)緊湊,便于存儲)
- Redis加載RDB恢復(fù)數(shù)據(jù)遠(yuǎn)遠(yuǎn)快于AOF的方式。(恢復(fù)速度快)
缺點:
- RDB方式數(shù)據(jù)沒辦法做到實時持久化/秒級持久化。因為bgsave每次運行都要執(zhí)行fork操作創(chuàng)建子進(jìn)程,屬于重量級操作,頻繁執(zhí)行成本過高。(成本高)
- RDB文件使用特定二進(jìn)制格式保存,Redis版本演進(jìn)過程中有多個格式的RDB版本,存在老版本Redis服務(wù)無法兼容新版RDB格式的問題。(不兼容)
5. AOF
AOF(append only file)持久化:以獨立日志的方式記錄每次寫命令,重啟時再重新執(zhí)行AOF文件中的命令達(dá)到恢復(fù)數(shù)據(jù)的目的。主要作用是解決了數(shù)據(jù)持久化的實時性。
6. AOF的使用方式
- 開啟AOF功能需要設(shè)置配置:appendonly yes,默認(rèn)不開啟。
- AOF文件名通過appendfilename配置設(shè)置,默認(rèn)文件名是appendonly.aof。(路徑同RDB)
- 主要流程有命令寫入(append)、文件同步(sync)、文件重寫(rewrite)、重啟加載(load)。
7. AOF流程剖析
流程描述:
- 所有的寫入命令會追加到aof_buf(緩沖區(qū))中。
- AOF緩沖區(qū)根據(jù)對應(yīng)的策略向硬盤做同步操作。
- 隨著AOF文件越來越大,需要定期對AOF文件進(jìn)行重寫,達(dá)到壓縮的目的。
- 當(dāng)Redis服務(wù)器重啟時,可以加載AOF文件進(jìn)行數(shù)據(jù)恢復(fù)。
7.1 命令寫入
AOF命令寫入的內(nèi)容直接是文本協(xié)議格式。例如set hello world這條命令,在AOF緩沖區(qū)會追加如下文本:
*3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\n
為什么使用文本協(xié)議格式?
- 文本協(xié)議具有很好的兼容性。(兼容性好)
- 開啟AOF后,所有寫入命令都包含追加操作,直接采用協(xié)議格式,避免了二次處理開銷。(處理簡單)
- 文本協(xié)議具有可讀性,方便直接修改和處理。(方便修改)
為什么要追加到aof_buf中而不是直接寫入硬盤?
- 如果每次寫AOF文件命令都直接追加到硬盤,那么Redis的性能就會受到硬盤讀寫速度的影響,而硬盤的讀寫速度相對于內(nèi)存則是數(shù)量級上的差距,所以如果每次直接寫入硬盤則勢必會大幅度影響Redis的運行速度。(影響運行速度)
- 使用緩沖區(qū)暫存,Redis還可以提供多種緩沖區(qū)同步硬盤的策略,在性能和安全性方面做出平衡。(可以針對具體場景干預(yù)刷盤策略,以達(dá)到更好的效果)
7.2 文件同步
Redis提供了多種AOF緩沖區(qū)同步文件策略,由參數(shù)appendfsync控制。
系統(tǒng)調(diào)用write和fsync的幾點說明:
- write :會觸發(fā)延遲寫(delayed write)機(jī)制。Linux在內(nèi)核提供頁緩沖區(qū)用來提高硬盤IO性能。write操作在寫入系統(tǒng)緩沖區(qū)后直接返回。同步硬盤操作依賴于系統(tǒng)調(diào)度機(jī)制,例如:緩沖區(qū)頁空間寫滿或達(dá)到特定時間周期。同步文件之前,如果此時系統(tǒng)故障宕機(jī),緩沖區(qū)內(nèi)數(shù)據(jù)將丟失。(寫緩沖,定期由操作系統(tǒng)刷盤)
- fsync :針對單個文件操作(比如AOF文件),做強(qiáng)制硬盤同步,fsync將阻塞直到寫入硬盤完成后返回,保證了數(shù)據(jù)持久化。(立即將緩沖數(shù)據(jù)刷盤)
策略的幾點說明:
- always:每次寫入都要同步AOF文件,在一般的SATA硬盤上,Redis只能支持大約幾百TPS寫入,顯然跟Redis高性能特性背道而馳,不建議配置。
- no:由于操作系統(tǒng)每次同步AOF文件的周期不可控,而且會加大每次同步硬盤的數(shù)據(jù)量,雖然提升了性能,但數(shù)據(jù)安全性無法保證。
- everysec:是建議的同步策略,也是默認(rèn)配置,做到兼顧性能和數(shù)據(jù)安全性。(在系統(tǒng)突然宕機(jī)的情況下丟失1~2秒的數(shù)據(jù))
7.3 重寫機(jī)制
為什么要重寫?:
- 隨著命令不斷寫入AOF,文件會越來越大。
- 會包含越來越多無用的命令記錄。(比如最近一次對一個值的更新操作,那么在此之前記錄的更新操作都會作廢)
- 更小的AOF文件可以更快地被Redis加載。
怎么重寫?:
- AOF文件重寫就是把Redis進(jìn)程內(nèi)的數(shù)據(jù)轉(zhuǎn)化為寫命令同步到新AOF文件。
重寫后那些優(yōu)化讓文件變小了?:
- 進(jìn)程內(nèi)已經(jīng)超時的數(shù)據(jù)不再寫入文件。(去除失效數(shù)據(jù))
- 舊的AOF文件含有無效命令,如del key1、hdel key2、srem keys、set a111、set a222等。重寫使用進(jìn)程內(nèi)數(shù)據(jù)直接生成,這樣新的AOF文件只保留最終數(shù)據(jù)的寫入命令。(去除無用命令)
- 多條寫命令可以合并為一個,如:lpush list a、lpush list b、lpush list c可以轉(zhuǎn)化為:lpush list a b c;為了防止單條命令過大造成客戶 端緩沖區(qū)溢出,對于list、set、hash、zset等類型操作,以64個元素為界拆分為多條。(使用批量命令)
重寫有那些觸發(fā)方式?:
- 手動觸發(fā) :直接調(diào)用bgrewriteaof命令。
- 自動觸發(fā) :根據(jù)auto-aof-rewrite-min-size和auto-aof-rewritepercentage參數(shù)確定自動觸發(fā)時機(jī)。
- auto-aof-rewrite-min-size:表示運行AOF重寫時文件最小體積,默認(rèn)為64MB。(根據(jù)當(dāng)前文件大小)
- auto-aof-rewrite-percentage:代表當(dāng)前AOF文件空間(aof_current_size)和上一次重寫后AOF文件空間(aof_base_size)的比值。(根據(jù)文件大小的增量)
自動觸發(fā)時機(jī):
aof_current_size > auto-aof-rewrite-minsize && (aof_current_size-aof_base_size)/aof_base_size >= auto-aof-rewrite-percentage
aof_current_size 和 aof_base_size 可以在info Persistence統(tǒng)計信息中查看。
重寫流程概述:
流程描述:
執(zhí)行AOF重寫請求。
- 如果當(dāng)前進(jìn)程正在執(zhí)行AOF重寫,請求不執(zhí)行并返回
ERR Background append only file rewriting already in progress
。 - 如果當(dāng)前進(jìn)程正在執(zhí)行bgsave操作,重寫命令延遲到bgsave完成之后再執(zhí)行,返回
Background append only file rewriting scheduled
- 如果當(dāng)前進(jìn)程正在執(zhí)行AOF重寫,請求不執(zhí)行并返回
- 父進(jìn)程執(zhí)行fork創(chuàng)建子進(jìn)程,開銷等同于bgsave過程。
- (1)主進(jìn)程fork操作完成后,繼續(xù)響應(yīng)其他命令。所有修改命令依然寫入AOF緩沖區(qū)并根據(jù)appendfsync策略同步到硬盤,保證原有AOF機(jī)制正確性。(2)由于fork操作運用寫時復(fù)制技術(shù)(Copy On Write),子進(jìn)程只能共享fork操作時的內(nèi)存數(shù)據(jù)。由于父進(jìn)程依然響應(yīng)命令,Redis使用“AOF重寫緩沖區(qū)”保存這部分新數(shù)據(jù),防止新AOF文件生成期間丟失這部分?jǐn)?shù)據(jù)。
- 子進(jìn)程根據(jù)內(nèi)存快照,按照命令合并規(guī)則寫入到新的AOF文件。每次批量寫入硬盤數(shù)據(jù)量由配置aof-rewrite-incremental-fsync控制,默認(rèn)為32MB,防止單次刷盤數(shù)據(jù)過多造成硬盤阻塞。
- (1)新AOF文件寫入完成后,子進(jìn)程發(fā)送信號給父進(jìn)程,父進(jìn)程更新統(tǒng)計信息,具體見info persistence的aof_*相關(guān)統(tǒng)計。(2)父進(jìn)程把AOF重寫緩沖區(qū)的數(shù)據(jù)寫入到新的AOF文件(3)并使用新AOF文件替換老文件,完成AOF重寫。
7.4 重啟加載
流程描述:
- AOF持久化開啟且存在AOF文件時,優(yōu)先加載AOF文件,并輸出
DB loaded from append only file: xxx seconds
。 - AOF關(guān)閉或者AOF文件不存在時,加載RDB文件,并輸出
DB loaded from disk: xxx seconds
。 - 加載AOF或RDB文件成功后,Redis啟動成功。
- AOF或RDB文件存在錯誤時,Redis啟動失敗并打印錯誤信息。
關(guān)于文件校驗:
加載損壞的AOF文件時會拒絕啟動,并會輸出:
Bad file format reading the append only file: make a backup of your AOF file,then use ./redis-check-aof --fix <filename>
對于錯誤格式的AOF文件:先進(jìn)行備份,然后采用redis-check-aof --fix命令進(jìn)行修復(fù),修復(fù)后使用diff-u對比數(shù)據(jù)的差異,找出丟失的數(shù)據(jù),有些可以人工修改補(bǔ)全。
對于AOF文件結(jié)尾不完整:比如機(jī)器突然掉電導(dǎo)致AOF尾部文件命令寫入不全。Redis為我們提供了aof-load-truncated配置來兼容這種情況,默認(rèn)開啟。加載AOF時,當(dāng)遇到此問題時會忽略并繼續(xù)啟動,同時打印如下警告日志:
# !!! Warning: short read while loading the AOF file !!! # !!! Truncating the AOF at offset 397856725 !!! # AOF loaded anyway because aof-load-truncated is enabled
8. 問題定位與優(yōu)化
8.1 關(guān)于fork操作
當(dāng)Redis做RDB或AOF重寫時,一個必不可少的操作就是執(zhí)行fork操作創(chuàng)建子進(jìn)程,對于大多數(shù)操作系統(tǒng)來說fork是個重量級操作雖然fork創(chuàng)建的子進(jìn)程不需要拷貝父進(jìn)程的物理內(nèi)存空間,但是會復(fù)制父進(jìn)程的空間內(nèi)存頁表,因此fork操作耗時跟進(jìn)程總內(nèi)存量息息相關(guān)??梢栽趇nfo stats統(tǒng)計中查latest_fork_usec指標(biāo)獲取最近一次fork操作耗時,單位微秒。
減少fork耗時的措施:
- 優(yōu)先使用物理機(jī)或者高效支持fork操作的虛擬化技術(shù),避免使用Xen。
- 控制Redis實例最大可用內(nèi)存,fork耗時跟內(nèi)存量成正比,線上建議每個Redis實例內(nèi)存控制在10GB以內(nèi)。
- 合理配置Linux內(nèi)存分配策略,避免物理內(nèi)存不足導(dǎo)致fork失敗。
- 降低fork操作的頻率,如適度放寬AOF自動觸發(fā)時機(jī),避免不必要的全量復(fù)制等。
8.2 關(guān)于子進(jìn)程開銷
CPU:
- 分析:子進(jìn)程負(fù)責(zé)把進(jìn)程內(nèi)的數(shù)據(jù)分批寫入文件,這個過程屬于CPU密集操作,通常子進(jìn)程對單核CPU利用率接近90%。
- 優(yōu)化:
- Redis是CPU密集型服務(wù),不要做綁定單核CPU操作。由于子進(jìn)程非常消耗CPU,會和父進(jìn)程產(chǎn)生單核資源競爭。
- 不要和其他CPU密集型服務(wù)部署在一起,造成CPU過度競爭。
- 如果部署多個Redis實例,盡量保證同一時刻只有一個子進(jìn)程執(zhí)行重寫工作。
內(nèi)存:
- 分析:得益于Linux的寫時復(fù)制機(jī)制(copy on write),父子進(jìn)程會共享相同的物理內(nèi)存頁,當(dāng)父進(jìn)程處理寫請求時會把要修改的頁創(chuàng)建副本,而子進(jìn)程在fork操作過程中共享整個父進(jìn)程內(nèi)存快照。(重寫時共享同一份物理內(nèi)存區(qū)域,內(nèi)存主要開銷在于 拷貝的頁表 和 應(yīng)用 copy on write 時某些頁的拷貝 以及在進(jìn)行AOF重寫所使用的 aof_rewrite_buf占用的大小 )
- 優(yōu)化:
- 如果部署多個Redis實例,盡量保證同一時刻只有一個子進(jìn)程在工作。
- 避免在大量寫入時做子進(jìn)程重寫操作,這樣將導(dǎo)致父進(jìn)程維護(hù)大量頁副本,造成內(nèi)存消耗。
- Linux kernel在2.6.38內(nèi)核增加了Transparent Huge Pages(THP),支持huge page(2MB)的頁分配,默認(rèn)開啟。當(dāng)開啟時可以降低fork創(chuàng) 建子進(jìn)程的速度,但執(zhí)行fork之后,如果開啟THP,復(fù)制頁單位從原來4KB變?yōu)?MB,會大幅增加重寫期間父進(jìn)程內(nèi)存消耗。
硬盤:
- 分析:子進(jìn)程主要職責(zé)是把AOF或者RDB文件寫入硬盤持久化,所以在執(zhí)行重寫的時候勢必會增加硬盤的寫入壓力。根據(jù)Redis重寫AOF或RDB的數(shù)據(jù)量,結(jié)合系統(tǒng)工具如sar、iostat、iotop等,可分析出重寫期間硬盤負(fù)載情況。
- 優(yōu)化:
- 不要和其他高硬盤負(fù)載的服務(wù)部署在一起。如:存儲服務(wù)、消息隊列服務(wù)等。
- AOF重寫時會消耗大量硬盤IO,可以開啟配置no-appendfsyncon-rewrite,默認(rèn)關(guān)閉。表示在AOF重寫期間不做fsync操作,注意!配置no-appendfsync-on-rewrite=yes時,在極端情況下可能丟失整個AOF重寫期間的數(shù)據(jù),需要根據(jù)數(shù)據(jù)安全性決定是否配置。
- 當(dāng)開啟AOF功能的Redis用于高流量寫入場景時,Redis的性能會受到硬盤寫入性能的影響。
- 對于單機(jī)配置多個Redis實例的情況,可以配置不同實例分盤存儲AOF文件,分?jǐn)傆脖P寫入壓力。
8.3 關(guān)于AOF追加阻塞
描述:當(dāng)開啟AOF持久化時,常用的同步硬盤的策略是everysec,用于平衡性能和數(shù)據(jù)安全性。對于這種方式,Redis使用另一條線程每秒執(zhí)行fsync同步硬盤。當(dāng)系統(tǒng)硬盤資源繁忙時,會造成Redis主線程阻塞。
問題定位:
- 發(fā)生AOF阻塞時,Redis輸出日志,用于記錄AOF fsync阻塞導(dǎo)致拖慢Redis服務(wù)的行為:
Asynchronous AOF fsync is taking too long (disk is busy). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redi
- 每當(dāng)發(fā)生AOF追加阻塞事件發(fā)生時,在info Persistence統(tǒng)計中,aof_delayed_fsync指標(biāo)會累加,查看這個指標(biāo)方便定位AOF阻塞問題。
- AOF同步最多允許2秒的延遲,當(dāng)延遲發(fā)生時說明硬盤存在高負(fù)載問題。
流程概述:
- 主線程負(fù)責(zé)寫入AOF緩沖區(qū)。
- AOF線程負(fù)責(zé)每秒執(zhí)行一次同步磁盤操作,并記錄最近一次同步時間。
- 主線程負(fù)責(zé)對比上次AOF同步時間:
- 如果距上次同步成功時間在2秒內(nèi),主線程直接返回。
- 如果距上次同步成功時間超過2秒,主線程將會阻塞,直到同步操作完成。
也就是說:
- everysec配置最多可能丟失2秒數(shù)據(jù),不是1秒。
- 如果系統(tǒng)fsync緩慢,將會導(dǎo)致Redis主線程阻塞影響效率。
到此這篇關(guān)于一文詳解Redis中的持久化的文章就介紹到這了,更多相關(guān)Redis持久化內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
基于redis實現(xiàn)世界杯排行榜功能項目實戰(zhàn)
前段時間,做了一個世界杯競猜積分排行榜。對世界杯64場球賽勝負(fù)平進(jìn)行猜測,猜對+1分,錯誤+0分,一人一場只能猜一次。下面通過本文給大家分享基于redis實現(xiàn)世界杯排行榜功能項目實戰(zhàn),感興趣的朋友一起看看吧2018-10-10Redis中?HyperLogLog數(shù)據(jù)類型使用小結(jié)
Redis使用HyperLogLog的主要作用是在大數(shù)據(jù)流(view,IP,城市)的情況下進(jìn)行去重計數(shù),這篇文章主要介紹了Redis中?HyperLogLog數(shù)據(jù)類型使用總結(jié),需要的朋友可以參考下2023-03-03