建站
咨詢
售后
建站咨詢
新聞中心
Redis 有兩種持久化方案，RDB （Redis DataBase）和 AOF （Append Only File），本篇文章重點為大家講解一下Redis AOF 持久化方式。
創(chuàng)新互聯建站是一家集網站建設,汝州企業(yè)網站建設,汝州品牌網站建設,網站定制,汝州網站建設報價,網絡營銷,網絡優(yōu)化,汝州網站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強企業(yè)競爭力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯網需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學習、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網站。
AOF 持久化的實現
示意圖
如上圖所示，AOF 持久化功能的實現可以分為命令追加( append )、文件寫入( write )、文件同步( sync )、文件重寫(rewrite)和重啟加載(load)。其流程如下：
命令追加
當 AOF 持久化功能處于打開狀態(tài)時，Redis 在執(zhí)行完一個寫命令之后，會以協議格式(也就是RESP，即 Redis 客戶端和服務器交互的通信協議 )將被執(zhí)行的寫命令追加到 Redis 服務端維護的 AOF 緩沖區(qū)末尾。
比如說 SET mykey myvalue 這條命令就以如下格式記錄到 AOF 緩沖中。
"*3\r\n$3\r\nSET\r\n$5\r\nmykey\r\n$7\r\nmyvalue\r\n"Redis 協議格式本文不再贅述，AOF之所以直接采用文本協議格式，是因為所有寫入命令都要進行追加操作，直接采用協議格式，避免了二次處理開銷。
文件寫入和同步
Redis 每次結束一個事件循環(huán)之前，它都會調用 flushAppendOnlyFile 函數，判斷是否需要將 AOF 緩存區(qū)中的內容寫入和同步到 AOF 文件中。
flushAppendOnlyFile 函數的行為由 redis.conf 配置中的 appendfsync 選項的值來決定。該選項有三個可選值，分別是 always、 everysec 和 no：
always：Redis 在每個事件循環(huán)都要將 AOF 緩沖區(qū)中的所有內容寫入到 AOF 文件，并且同步 AOF 文件，所以always 的效率是appendfsync 選項三個值當中最差的一個，但從安全性來說，也是最安全的。當發(fā)生故障停機時，AOF 持久化也只會丟失一個事件循環(huán)中所產生的命令數據。everysec：Redis 在每個事件循環(huán)都要將 AOF 緩沖區(qū)中的所有內容寫入到 AOF 文件中，并且每隔一秒就要在子線程中對 AOF 文件進行一次同步。從效率上看，該模式足夠快。當發(fā)生故障停機時，只會丟失一秒鐘的命令數據。no：Redis 在每一個事件循環(huán)都要將 AOF 緩沖區(qū)中的所有內容寫入到 AOF 文件。而 AOF 文件的同步由操作系統(tǒng)控制。這種模式下速度最快，但是同步的時間間隔較長，出現故障時可能會丟失較多數據。Linux 系統(tǒng)下 write 操作會觸發(fā)延遲寫( delayed write )機制。Linux 在內核提供頁緩存區(qū)用來提供硬盤 IO 性能。 write 操作在寫入系統(tǒng)緩沖區(qū)之后直接返回。同步硬盤操作依賴于系統(tǒng)調度機制，例如：緩沖區(qū)頁空間寫滿或者達到特定時間周期。同步文件之前，如果此時系統(tǒng)故障宕機，緩沖區(qū)內數據將丟失。
而 fsync 針對單個文件操作，對其進行強制硬盤同步， fsync 將阻塞直到寫入磁盤完成后返回，保證了數據持久化。
appendfsync的三個值代表著三種不同的調用 fsync的策略。調用 fsync周期越頻繁，讀寫效率就越差，但是相應的安全性越高，發(fā)生宕機時丟失的數據越少。
有關 Linux 的I/O和各個系統(tǒng)調用的作用如下圖所示。具體內容可以查看《聊聊 Linux I/O》一文。
AOF 數據恢復
AOF 文件里邊包含了重建 Redis 數據所需的所有寫命令，所以 Redis 只要讀入并重新執(zhí)行一遍 AOF 文件里邊保存的寫命令，就可以還原 Redis 關閉之前的狀態(tài)。
Redis 讀取 AOF 文件并且還原數據庫狀態(tài)的詳細步驟如下：
當完成以上步驟之后，AOF 文件所保存的數據庫狀態(tài)就會被完整還原出來。
AOF 重寫
因為 AOF 持久化是通過保存被執(zhí)行的寫命令來記錄 Redis 狀態(tài)的，所以隨著 Redis 長時間運行，AOF 文件中的內容會越來越多，文件的體積也會越來越大，如果不加以控制的話，體積過大的 AOF 文件很可能對 Redis 甚至宿主計算機造成影響。
為了解決 AOF 文件體積膨脹的問題，Redis 提供了 AOF 文件重寫( rewrite) 功能。通過該功能，Redis 可以創(chuàng)建一個新的 AOF 文件來替代現有的 AOF 文件。新舊兩個 AOF 文件所保存的 Redis 狀態(tài)相同，但是新的 AOF 文件不會包含任何浪費空間的榮譽命令，所以新 AOF 文件的體積通常比舊 AOF 文件的體積要小得很多。
示意圖
如上圖所示，重寫前要記錄名為 list的鍵的狀態(tài)，AOF 文件要保存五條命令，而重寫后，則只需要保存一條命令。
AOF 文件重寫并不需要對現有的 AOF 文件進行任何讀取、分析或者寫入操作，而是通過讀取服務器當前的數據庫狀態(tài)來實現的。首先從數據庫中讀取鍵現在的值，然后用一條命令去記錄鍵值對，代替之前記錄這個鍵值對的多條命令，這就是 AOF 重寫功能的實現原理。
在實際過程中，為了避免在執(zhí)行命令時造成客戶端輸入緩沖區(qū)溢出，AOF 重寫在處理列表、哈希表、集合和有序集合這四種可能會帶有多個元素的鍵時，會先檢查鍵所包含的元素數量，如果數量超過 REDISAOFREWRITEITEMSPER_CMD ( 一般為64 )常量，則使用多條命令記錄該鍵的值，而不是一條命令。
rewrite的觸發(fā)機制主要有一下三個：
AOF 后臺重寫
AOF 重寫函數會進行大量的寫入操作，調用該函數的線程將被長時間阻塞，所以 Redis 在子進程中執(zhí)行 AOF 重寫操作。
但是，在子進程進行 AOF 重啟期間，Redis接收客戶端命令，會對現有數據庫狀態(tài)進行修改，從而導致數據當前狀態(tài)和 重寫后的 AOF 文件所保存的數據庫狀態(tài)不一致。
為此，Redis 設置了一個 AOF 重寫緩沖區(qū)，這個緩沖區(qū)在服務器創(chuàng)建子進程之后開始使用，當 Redis 執(zhí)行完一個寫命令之后，它會同時將這個寫命令發(fā)送給 AOF 緩沖區(qū)和 AOF 重寫緩沖區(qū)。
當子進程完成 AOF 重寫工作之后，它會向父進程發(fā)送一個信號，父進程在接收到該信號之后，會調用一個信號處理函數，并執(zhí)行以下工作：
在整個 AOF 后臺重寫過程中，只有信號處理函數執(zhí)行時會對 Redis 主進程造成阻塞，在其他時候，AOF 后臺重寫都不會阻塞主進程。
網站題目：RedisAOF持久化方式
網站URL：http://m.5511xx.com/article/cdcppsc.html
