天天在用Redis,那你對Redis的AOF持久化到底瞭解多少呢?

来源:https://www.cnblogs.com/yunxi520/archive/2020/05/30/12993091.html

為什麼需要持久化,以及Redis持久化的RDB方式在這篇文章講的已經很透徹了,足以弔打面試官了。而且此篇內容需要RDB文章的內容支持,所以建議先看下:看完這篇還不懂Redis的RDB持久化,你們來打我! 一、什麼是AOF 它也是Redis持久化的重要手段之一,aof->Append Only Fil ...


為什麼需要持久化,以及Redis持久化的RDB方式在這篇文章講的已經很透徹了,足以弔打面試官了。而且此篇內容需要RDB文章的內容支持,所以建議先看下:看完這篇還不懂Redis的RDB持久化,你們來打我!

一、什麼是AOF

它也是Redis持久化的重要手段之一,aof->Append Only File,只追加文件,也就是每次處理完請求命令後都會將此命令追加到aof文件的末尾。而RDB是壓縮成二進位等時機開子進程去乾這件事。

二、優缺點

1、優點

  • 持久化的速度快,因為每次都只是追加,rdb每次都全量持久化
  • 數據相對更可靠,丟失少,因可以配置每秒持久化、每個命令執行完就持久化

2、缺點

  • 災難性恢復的時候過慢,因為aof每次都只追加原命令,導致aof文件過大,但是後面會rewrite,但是相對於rdb也是慢的。
  • 會對主進程對外提供請求的效率造成影響,接收請求、處理請求、寫aof文件這三步是串列原子執行的。而非非同步多線程執行的。Redis單線程!

三、AOF原理

1、基礎原理

就是每次都在aof文件後面追加命令。他與主進程收到請求、處理請求是串列化的,而非非同步並行的。圖示如下

天天在用Redis,那你對Redis的AOF持久化到底瞭解多少呢?

 

在這裡插入圖片描述

所以aof的頻率高的話絕逼會對Redis帶來性能影響,因為每次都是刷盤操作。跟mysql一樣了。Redis每次都是先將命令放到緩衝區,然後根據具體策略(每秒/每條指令/緩衝區滿)進行刷盤操作。如果配置的always,那麼就是典型阻塞,如果是sec,每秒的話,那麼會開一個同步線程去每秒進行刷盤操作,對主線程影響稍小。

2、額外擴展

其實Redis每次在寫入AOF緩衝區之前,他都會調用flushAppendOnlyFile(),判斷是否需要將AOF緩衝區的內容寫入和同步到AOF文件中。這個決策是由配置文件的三個策略來控制的

  • always
  • everysec
  • no

四、REWRITE

1、為什麼要rewrite?

比如我有業務很簡單,就來回delete set 同一個key。就這個業務運行了10年,那麼aof文件將記錄無數個delete k1, set k1 xxx。其實都是重覆的,但是我aof每次都追加,文件變成了1T大小。這時候Redis宕機了,要恢復,你想想1TB大小的aof文件去恢復,累死了。最主要的是1TB大小隻記錄了兩個命令,所以壓縮其實就是來處理這件事的。

2、4.0版本之前的rewrite

Redis4.0之前和Redis4.0的rewrite(重寫)方式不一樣,Redis4.0之前就是將aof文件中重覆的命令給去掉。保留最新的命令。進而減少aof文件大小。比如

set k1 123
set k1 345
del k1
set k1 789

經過rewrite後(Redis4.0之前),只會變成如下

set k1 789

3、4.0版本以及之後的rewrite

4.0之前的做法效率很是低下,需要逐條命令對比。4.0開始的rewrite支持混合模式(也是就是rdb和aof一起用),直接將rdb持久化的方式來操作將二進位內容覆蓋到aof文件中(rdb是二進位,所以很小),然後再有寫入的話還是繼續append追加到文件原始命令,等下次文件過大的時候再次rewrite(還是按照rdb持久化的方式將內容覆蓋到aof中)。但是這種模式也是配置的,預設是開,也可以關閉。

4、rewrite觸發條件

1、手動觸發

  • 客戶端執行bgrewriteaof命令

2、自動觸發

通過以下兩個配置協作觸發

auto-aof-rewrite-min-size

AOF文件最小重寫大小,只有當AOF文件大小大於該值時候才可能重寫,4.0預設配置64mb。

auto-aof-rewrite-percentage

當前AOF文件大小和最後一次重寫後的大小之間的比率等於或者等於指定的增長百分比,如100代表當前AOF文件是上次重寫的兩倍時候才重寫。 

3、觸發滿足條件

  • 沒有BGSAVE命令(RDB持久化)/AOF持久化在執行
  • 沒有BGREWRITEAOF在進行;

前兩點也就是說只允許同時fork()一個子進程出來幹活。

  • 當前AOF文件大小要大於server.aof_rewrite_min_size的值;
  • 當前AOF文件大小和最後一次重寫後的大小之間的比率等於或者大於指定的增長百分比(auto-aof-rewrite-percentage參數)

5、rewrite原理

4.0之前版本的,和4.0以及之後關閉混合模式的情況下。

天天在用Redis,那你對Redis的AOF持久化到底瞭解多少呢?

 

在這裡插入圖片描述

  • aof_rewrite_buf:rewrite(重寫)緩衝區、aof_buf:寫命令存放的緩衝區
  • 開始bgrewriteaof的時候,判斷當前有沒有bgsave/bgrewriteaof在執行,若有,則不執行,這個再rdb篇幅也有提到,以及下麵很多fork()知識在rdb都有提到。看完這篇還不懂Redis的RDB持久化,你們來打我!
  • 主進程fork()出子進程,在執行fork()這個方法的時候是阻塞的,子進程創建完畢後就不阻塞了
  • 主進程fork完子進程後,主進程能繼續接收客戶端的請求,所有寫命令依然是寫入AOF文件緩衝區並根據配置文件的策略同步到磁碟的。
  • 因為fork的子進程僅僅共用主進程fork()時的記憶體,後期主進程在更改記憶體數據,子進程是不可見的。因此Redis採取重寫緩衝區(aof_rewite_buf)保存fork之後的客戶端請求。防止新AOF文件生成期間丟失主進程執行的新命令所生成的數據。所以此時客戶端的寫請求不僅僅寫入原來的aof_buf緩衝區,還寫入了重寫緩衝區。這就是我為什麼用深藍色的框給他兩框到一起的原因。
  • 子進程通過記憶體快照的形式,開始生成新的aof文件。
  • 新aof文件生成完後,子進程向主進程發信號。
  • 主進程收到信號後,會把重寫緩衝區(aof_rewite_buf)中的數據寫入到新的AOF文件(主要是避免這部分數據丟失)
  • 使用新的AOF文件覆蓋舊的AOF文件,且標記AOF重寫完成。

五、RDB-AOF混合持久化

redis4.0之後才支持,預設開啟

1、優點

混合持久化結合了RDB持久化 和 AOF 持久化的優點,採取了rdb的文件小易於災難恢復,同時結合AOF,增量的數據以AOF方式保存了,數據更少的丟失。

2、缺點

相容性差,一旦開啟了混合持久化,在4.0之前版本都不識別該aof文件,同時由於前部分是RDB格式,需要專業的工具來閱讀,因為是二進位,所以閱讀性較差。

3、原理

需要先掌握看完這篇還不懂Redis的RDB持久化,你們來打我!和此篇幅的aof

混合持久化也是通過bgrewriteaof完成的,所以基本流程和上述一樣。不同的是當開啟混合模式時,fork出的子進程先將共用的記憶體副本全量以RDB的方式寫入aof。這樣提高了速度也極大的縮小了aof文件(畢竟都是二進位)。寫完還是通知主進程,然後再將重寫緩衝區的內容以AOF方式寫入到文件,然後替換舊的aof文件。也就是說這種模式下的aof文件發生rewrite後前半部分是rdb格式(REDIS開頭的二進位數據),後半部分是正常的aof追加的命令(重寫緩衝區里的)。

4、數據恢復

會優先看是否存在aof文件,若存在則先按照aof文件恢復,因為aof畢竟比rdb全。若aof不存在,則才會查找rdb是否存在。這是預設的機制。畢竟aof文件也rewrite成rdb二進位格式,文件小,易於回覆。所以redis會優先採取aof。

六、總結

此篇都是重點,廢話很少。沒啥可總結的。

最後小編整理了一套技術資料不僅能精準消除技術盲點、累計面試經驗,更可以攻剋JVM、Spring、分散式、微服務等技術難題。

天天在用Redis,那你對Redis的AOF持久化到底瞭解多少呢?

 

海量電子書,珍藏版

天天在用Redis,那你對Redis的AOF持久化到底瞭解多少呢?

 

天天在用Redis,那你對Redis的AOF持久化到底瞭解多少呢?

 

天天在用Redis,那你對Redis的AOF持久化到底瞭解多少呢?

 

天天在用Redis,那你對Redis的AOF持久化到底瞭解多少呢?

領取步驟

1.加微信獲取


您的分享是我們最大的動力!

更多相關文章
  • 引言 Kafka是一款很棒的消息系統,今天我們就來深入瞭解一下它的實現細節,首先關註Producer這一方。 要使用kafka首先要實例化一個KafkaProducer,需要有brokerIP、序列化器等必要Properties以及acks(0、1、n)、compression、retries、ba ...
  • 在上一篇文章中我們創建了第一個項目 Hello World ,項目是創建好了,但還不知道這個 Hello World 是個啥玩意?到底怎麼運行? 一.Hello World源碼 我們將hello world.cpp的內容修改如下如下: // hello world.cpp : 定義控制台應用程式的入 ...
  • Java程式員為什麼要瞭解虛擬機相關的知識 Java程式在設計之初就號稱“一次編譯,到處運行”。Java之所以能做到“一次編譯,處處運行”是因為Java虛擬機隱藏了底層技術的複雜性以及機器和操作系統的差異性。 運行程式的物理機千差萬別,而Java虛擬機則在千差萬別的物理機上面建立了統一的運行平臺,實 ...
  • Spring Boot的配置(配置文件,載入順序,配置原理)之配置文件 配置文件 Spring Boot使用一個全局配置文件,配置文件名是固定的 application.properties application.yml 配置文件的作用:修改Spring Boot自動配置的預設值,即修改Sprin ...
  • Fiddler Fiddler是位於客戶端和伺服器端的HTTP代理,也是目前最常用的http抓包工具之一 。它能夠記錄客戶端和伺服器之間的所有 HTTP請求,可以針對特定的HTTP請求,分析請求數據、設置斷點、調試web應用、修改請求的數據,甚至可以修改伺服器返回的數據,功能非常強大,是web調試的 ...
  • 寫在最後 程式員為何害怕【別人的代碼】呢?這讓我想起一個段子。 寫這段代碼時 只有上帝和我知道他是幹嘛的 現在 只有上帝知道了 別人的代碼,似乎總意味著冗長、晦澀、凌亂,給人一種不想靠近的感覺。搞笑的是,對於一些程式員而言,即使是自己的代碼,在一段時間之後自己再拿來看,也成了【別人的代碼】... 作 ...
  • 概括來說,分三步: 1,首先找到是哪個進程的CPU占有率飆到了100%。 2,根據進程號pid,定位到是哪個線程,找到對應線程的tid。 3,導出對應線程的dump日誌文件,分析日誌文件定位具體代碼。 要解決這個問題,你應該具備以下技能: 1,linux的top命令。 2,jvm監控工具jps。 3 ...
  • 先上圖: @IT程式猿 微博網友評論: @迢書:前同事的,親眼見過 @AvenGeeker:Bug 404 @科技州:這是要逼死強迫症 @小島一瞥:哈哈哈哈哈我老家的車 最後小編整理了一套技術資料不僅能精準消除技術盲點、累計面試經驗,更可以攻剋JVM、Spring、分散式、微服務等技術難題。 海量電 ...
一周排行
  • C#6.0新特性 C#7.0新特性 C#8.0新特性 ...
  • out變數 可以直接在方法中使用out申明變數 int.TryParse("123", out var result); 元組 元組的申明 var alphaBetaStart = (alpha: "a", beta: "b"); Console.WriteLine($"{alphaBetaStar ...
  • 在我們的項目中,通常會把數據存儲到關係型資料庫中,比如Oracle,SQL Server,Mysql等,但是關係型資料庫對於併發的支持並不是很強大,這樣就會造成系統的性能不佳,而且存儲的數據多為結構化數據,對於非結構數據(比如文本)和半結構化數據(比如JSon) 就顯得不夠靈活,而非關係型資料庫則很 ...
  • 這幾天終於弄懂了async和await的模式,也搞明白了一直在心裡面積壓著的許多問題,所以寫一篇博客來和大家分享一下。 關於非同步機制我認為只要記住的以下幾點,就可以弄明白了: 1.我認為async和awwait兩個修飾符中最關鍵的是await,async是由於方法中包含await修飾符之後才在方法定 ...
  • 實現WCF的步驟如下: 設計服務協議 實現服務協議 配置服務 托管服務 生成客戶端(這步可有可無) 設計或定義服務協議要麼使用介面,要麼使用類。建議介面,使用介面好處一堆例如修改介面的實現,但是服務協定有無需改變。 設計服務協議,介面上使用 ServiceContractAttribute ,方法上 ...
  • 什麼鬼,我的CPF快寫好了,你居然也要搞跨平臺UI框架?什麼Maui? 之前怎麼不早說要搞跨平臺UI框架呢?看到谷歌搞flutter眼紅了?明年年底發佈?又搞這種追別人屁股的爛事情。 什麼MVU模式?模仿Dart?用C#代碼直接寫UI的模式和我的CPF很像啊。 當初我考慮過XML,Json來描述UI ...
  • 寫在前面 Docker作為開源的應用容器引擎,可以讓我們很輕鬆的構建一個輕量級、易移植的容器,通過Docker方式進行持續交付、測試和部署,都是極為方便的,並且對於我們開發來說,最直觀的優點還是解決了日常開發中的環境配置與部署環境配置上的差異所帶來的種種疑難雜症,從此推脫產品的措辭也少了——“我電腦 ...
  • 一、前言 回顧:認證授權方案之授權初識 從上一節中,我們在對授權系統已經有了初步的認識和使用,可以發現,asp.net core為我們提供的授權策略是一個非常強大豐富且靈活的認證授權方案,能夠滿足大部分的授權場景。 在ConfigureServices中配置服務:將授權服務添加到容器 public ...
  • 項目背景: 工作之餘兼職一家公司(方向是工業4.0)給做IM系統,主要功能包括:文字、 圖片、文件傳輸、遠程協助、視頻語音等等。這些功能都是基於群會話, 比如工廠操作工人遇到問題,請求遠程專家,這個初級專家不能解決問題,會邀請一個高級專家進來解決。開發過程中主要遇到的問題是視頻和語音這一塊,像其他的... ...
  • 基礎概念 Microsoft中間語言(MSIL),也成為通用中間語言(CIL),是一組與平臺無關的指令,由特定於語言的編譯器從源代碼生成。MSIL是獨立於平臺的,因此,他可以在任何公共語言基礎架構支持特定的環境上執行。 通過JIT編譯器將MSIL轉換為特定電腦環境的特定機器代碼。這是在執行MSIL ...