日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時(shí)間:8:30-17:00
你可能遇到了下面的問(wèn)題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷解決方案
RedisAOF持久化方式

Redis 有兩種持久化方案,RDB (Redis DataBase)和 AOF (Append Only File),本篇文章重點(diǎn)為大家講解一下Redis AOF 持久化方式。

創(chuàng)新互聯(lián)建站是一家集網(wǎng)站建設(shè),汝州企業(yè)網(wǎng)站建設(shè),汝州品牌網(wǎng)站建設(shè),網(wǎng)站定制,汝州網(wǎng)站建設(shè)報(bào)價(jià),網(wǎng)絡(luò)營(yíng)銷,網(wǎng)絡(luò)優(yōu)化,汝州網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè),幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競(jìng)爭(zhēng)力??沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時(shí)我們時(shí)刻保持專業(yè)、時(shí)尚、前沿,時(shí)刻以成就客戶成長(zhǎng)自我,堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己,讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。

AOF 持久化的實(shí)現(xiàn)

示意圖

如上圖所示,AOF 持久化功能的實(shí)現(xiàn)可以分為命令追加( append )、文件寫入( write )、文件同步( sync )、文件重寫(rewrite)和重啟加載(load)。其流程如下:

所有的寫命令會(huì)追加到 AOF 緩沖中。
AOF 緩沖區(qū)根據(jù)對(duì)應(yīng)的策略向硬盤進(jìn)行同步操作。
隨著 AOF 文件越來(lái)越大,需要定期對(duì) AOF 文件進(jìn)行重寫,達(dá)到壓縮的目的。
當(dāng) Redis 重啟時(shí),可以加載 AOF 文件進(jìn)行數(shù)據(jù)恢復(fù)。

命令追加

當(dāng) AOF 持久化功能處于打開狀態(tài)時(shí),Redis 在執(zhí)行完一個(gè)寫命令之后,會(huì)以協(xié)議格式(也就是RESP,即 Redis 客戶端和服務(wù)器交互的通信協(xié)議 )將被執(zhí)行的寫命令追加到 Redis 服務(wù)端維護(hù)的 AOF 緩沖區(qū)末尾。

比如說(shuō) SET mykey myvalue 這條命令就以如下格式記錄到 AOF 緩沖中。

"*3\r\n$3\r\nSET\r\n$5\r\nmykey\r\n$7\r\nmyvalue\r\n"

Redis 協(xié)議格式本文不再贅述,AOF之所以直接采用文本協(xié)議格式,是因?yàn)樗袑懭朊疃家M(jìn)行追加操作,直接采用協(xié)議格式,避免了二次處理開銷。

文件寫入和同步

Redis 每次結(jié)束一個(gè)事件循環(huán)之前,它都會(huì)調(diào)用 flushAppendOnlyFile 函數(shù),判斷是否需要將 AOF 緩存區(qū)中的內(nèi)容寫入和同步到 AOF 文件中。

flushAppendOnlyFile 函數(shù)的行為由 redis.conf 配置中的 appendfsync 選項(xiàng)的值來(lái)決定。該選項(xiàng)有三個(gè)可選值,分別是 always、 everysecno

always:Redis 在每個(gè)事件循環(huán)都要將 AOF 緩沖區(qū)中的所有內(nèi)容寫入到 AOF 文件,并且同步 AOF 文件,所以
always 的效率是
appendfsync 選項(xiàng)三個(gè)值當(dāng)中最差的一個(gè),但從安全性來(lái)說(shuō),也是最安全的。當(dāng)發(fā)生故障停機(jī)時(shí),AOF 持久化也只會(huì)丟失一個(gè)事件循環(huán)中所產(chǎn)生的命令數(shù)據(jù)。
everysec:Redis 在每個(gè)事件循環(huán)都要將 AOF 緩沖區(qū)中的所有內(nèi)容寫入到 AOF 文件中,并且每隔一秒就要在子線程中對(duì) AOF 文件進(jìn)行一次同步。從效率上看,該模式足夠快。當(dāng)發(fā)生故障停機(jī)時(shí),只會(huì)丟失一秒鐘的命令數(shù)據(jù)。
no:Redis 在每一個(gè)事件循環(huán)都要將 AOF 緩沖區(qū)中的所有內(nèi)容寫入到 AOF 文件。而 AOF 文件的同步由操作系統(tǒng)控制。這種模式下速度最快,但是同步的時(shí)間間隔較長(zhǎng),出現(xiàn)故障時(shí)可能會(huì)丟失較多數(shù)據(jù)。

Linux 系統(tǒng)下 write 操作會(huì)觸發(fā)延遲寫( delayed write )機(jī)制。Linux 在內(nèi)核提供頁(yè)緩存區(qū)用來(lái)提供硬盤 IO 性能。 write 操作在寫入系統(tǒng)緩沖區(qū)之后直接返回。同步硬盤操作依賴于系統(tǒng)調(diào)度機(jī)制,例如:緩沖區(qū)頁(yè)空間寫滿或者達(dá)到特定時(shí)間周期。同步文件之前,如果此時(shí)系統(tǒng)故障宕機(jī),緩沖區(qū)內(nèi)數(shù)據(jù)將丟失。

fsync 針對(duì)單個(gè)文件操作,對(duì)其進(jìn)行強(qiáng)制硬盤同步, fsync 將阻塞直到寫入磁盤完成后返回,保證了數(shù)據(jù)持久化。

appendfsync的三個(gè)值代表著三種不同的調(diào)用 fsync的策略。調(diào)用 fsync周期越頻繁,讀寫效率就越差,但是相應(yīng)的安全性越高,發(fā)生宕機(jī)時(shí)丟失的數(shù)據(jù)越少。

有關(guān) Linux 的I/O和各個(gè)系統(tǒng)調(diào)用的作用如下圖所示。具體內(nèi)容可以查看《聊聊 Linux I/O》一文。

AOF 數(shù)據(jù)恢復(fù)

AOF 文件里邊包含了重建 Redis 數(shù)據(jù)所需的所有寫命令,所以 Redis 只要讀入并重新執(zhí)行一遍 AOF 文件里邊保存的寫命令,就可以還原 Redis 關(guān)閉之前的狀態(tài)。

Redis 讀取 AOF 文件并且還原數(shù)據(jù)庫(kù)狀態(tài)的詳細(xì)步驟如下:

創(chuàng)建一個(gè)不帶網(wǎng)絡(luò)連接的的偽客戶端( fake client),因?yàn)?Redis 的命令只能在客戶端上下文中執(zhí)行,而載入 AOF 文件時(shí)所使用的的命令直接來(lái)源于 AOF 文件而不是網(wǎng)絡(luò)連接,所以服務(wù)器使用了一個(gè)沒(méi)有網(wǎng)絡(luò)連接的偽客戶端來(lái)執(zhí)行 AOF 文件保存的寫命令,偽客戶端執(zhí)行命令的效果和帶網(wǎng)絡(luò)連接的客戶端執(zhí)行命令的效果完全一樣的。
從 AOF 文件中分析并取出一條寫命令。
使用偽客戶端執(zhí)行被讀出的寫命令。
一直執(zhí)行步驟 2 和步驟3,直到 AOF 文件中的所有寫命令都被處理完畢為止。

當(dāng)完成以上步驟之后,AOF 文件所保存的數(shù)據(jù)庫(kù)狀態(tài)就會(huì)被完整還原出來(lái)。

AOF 重寫

因?yàn)?AOF 持久化是通過(guò)保存被執(zhí)行的寫命令來(lái)記錄 Redis 狀態(tài)的,所以隨著 Redis 長(zhǎng)時(shí)間運(yùn)行,AOF 文件中的內(nèi)容會(huì)越來(lái)越多,文件的體積也會(huì)越來(lái)越大,如果不加以控制的話,體積過(guò)大的 AOF 文件很可能對(duì) Redis 甚至宿主計(jì)算機(jī)造成影響。

為了解決 AOF 文件體積膨脹的問(wèn)題,Redis 提供了 AOF 文件重寫( rewrite) 功能。通過(guò)該功能,Redis 可以創(chuàng)建一個(gè)新的 AOF 文件來(lái)替代現(xiàn)有的 AOF 文件。新舊兩個(gè) AOF 文件所保存的 Redis 狀態(tài)相同,但是新的 AOF 文件不會(huì)包含任何浪費(fèi)空間的榮譽(yù)命令,所以新 AOF 文件的體積通常比舊 AOF 文件的體積要小得很多。

示意圖

如上圖所示,重寫前要記錄名為 list的鍵的狀態(tài),AOF 文件要保存五條命令,而重寫后,則只需要保存一條命令。

AOF 文件重寫并不需要對(duì)現(xiàn)有的 AOF 文件進(jìn)行任何讀取、分析或者寫入操作,而是通過(guò)讀取服務(wù)器當(dāng)前的數(shù)據(jù)庫(kù)狀態(tài)來(lái)實(shí)現(xiàn)的。首先從數(shù)據(jù)庫(kù)中讀取鍵現(xiàn)在的值,然后用一條命令去記錄鍵值對(duì),代替之前記錄這個(gè)鍵值對(duì)的多條命令,這就是 AOF 重寫功能的實(shí)現(xiàn)原理。

在實(shí)際過(guò)程中,為了避免在執(zhí)行命令時(shí)造成客戶端輸入緩沖區(qū)溢出,AOF 重寫在處理列表、哈希表、集合和有序集合這四種可能會(huì)帶有多個(gè)元素的鍵時(shí),會(huì)先檢查鍵所包含的元素?cái)?shù)量,如果數(shù)量超過(guò) REDISAOFREWRITEITEMSPER_CMD ( 一般為64 )常量,則使用多條命令記錄該鍵的值,而不是一條命令。

rewrite的觸發(fā)機(jī)制主要有一下三個(gè):

手動(dòng)調(diào)用 bgrewriteaof 命令,如果當(dāng)前有正在運(yùn)行的 rewrite 子進(jìn)程,則本次rewrite 會(huì)推遲執(zhí)行,否則,直接觸發(fā)一次 rewrite。
通過(guò)配置指令手動(dòng)開啟 AOF 功能,如果沒(méi)有 RDB 子進(jìn)程的情況下,會(huì)觸發(fā)一次 rewrite,將當(dāng)前數(shù)據(jù)庫(kù)中的數(shù)據(jù)寫入 rewrite 文件。
在 Redis 定時(shí)器中,如果有需要退出執(zhí)行的 rewrite 并且沒(méi)有正在運(yùn)行的 RDB 或者 rewrite 子進(jìn)程時(shí),觸發(fā)一次或者 AOF 文件大小已經(jīng)到達(dá)配置的 rewrite 條件也會(huì)自動(dòng)觸發(fā)一次。

AOF 后臺(tái)重寫

AOF 重寫函數(shù)會(huì)進(jìn)行大量的寫入操作,調(diào)用該函數(shù)的線程將被長(zhǎng)時(shí)間阻塞,所以 Redis 在子進(jìn)程中執(zhí)行 AOF 重寫操作。

子進(jìn)程進(jìn)行 AOF 重寫期間,Redis 進(jìn)程可以繼續(xù)處理客戶端命令請(qǐng)求。
子進(jìn)程帶有父進(jìn)程的內(nèi)存數(shù)據(jù)拷貝副本,在不適用鎖的情況下,也可以保證數(shù)據(jù)的安全性。

但是,在子進(jìn)程進(jìn)行 AOF 重啟期間,Redis接收客戶端命令,會(huì)對(duì)現(xiàn)有數(shù)據(jù)庫(kù)狀態(tài)進(jìn)行修改,從而導(dǎo)致數(shù)據(jù)當(dāng)前狀態(tài)和 重寫后的 AOF 文件所保存的數(shù)據(jù)庫(kù)狀態(tài)不一致。

為此,Redis 設(shè)置了一個(gè) AOF 重寫緩沖區(qū),這個(gè)緩沖區(qū)在服務(wù)器創(chuàng)建子進(jìn)程之后開始使用,當(dāng) Redis 執(zhí)行完一個(gè)寫命令之后,它會(huì)同時(shí)將這個(gè)寫命令發(fā)送給 AOF 緩沖區(qū)和 AOF 重寫緩沖區(qū)。

當(dāng)子進(jìn)程完成 AOF 重寫工作之后,它會(huì)向父進(jìn)程發(fā)送一個(gè)信號(hào),父進(jìn)程在接收到該信號(hào)之后,會(huì)調(diào)用一個(gè)信號(hào)處理函數(shù),并執(zhí)行以下工作:

將 AOF 重寫緩沖區(qū)中的所有內(nèi)容寫入到新的 AOF 文件中,保證新 AOF 文件保存的數(shù)據(jù)庫(kù)狀態(tài)和服務(wù)器當(dāng)前狀態(tài)一致。
對(duì)新的 AOF 文件進(jìn)行改名,原子地覆蓋現(xiàn)有 AOF 文件,完成新舊文件的替換
繼續(xù)處理客戶端請(qǐng)求命令。

在整個(gè) AOF 后臺(tái)重寫過(guò)程中,只有信號(hào)處理函數(shù)執(zhí)行時(shí)會(huì)對(duì) Redis 主進(jìn)程造成阻塞,在其他時(shí)候,AOF 后臺(tái)重寫都不會(huì)阻塞主進(jìn)程。


分享標(biāo)題:RedisAOF持久化方式
URL分享:http://www.5511xx.com/article/cdcppsc.html