redis中RDB和AOP持久化是什么

小編給大家分享一下redis中RDB和AOP持久化是什么，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

redis是一個內(nèi)存數(shù)據(jù)庫，數(shù)據(jù)保存在內(nèi)存中，但是我們都知道內(nèi)存的數(shù)據(jù)變化是很快的，也容易發(fā)生丟失。幸好Redis還為我們提供了持久化的機制，分別是RDB(Redis DataBase)和AOF(Append Only File)。

在這里假設(shè)你已經(jīng)了解了redis的基礎(chǔ)語法，某字母網(wǎng)站都有很好的教程，可以去看。基本使用的文章就不寫了，都是一些常用的命令。

一、持久化流程

既然redis的數(shù)據(jù)可以保存在磁盤上，那么這個流程是什么樣的呢？

要有下面五個過程：

（1）客戶端向服務(wù)端發(fā)送寫操作(數(shù)據(jù)在客戶端的內(nèi)存中)。

（2）數(shù)據(jù)庫服務(wù)端接收到寫請求的數(shù)據(jù)(數(shù)據(jù)在服務(wù)端的內(nèi)存中)。

（3）服務(wù)端調(diào)用write這個系統(tǒng)調(diào)用，將數(shù)據(jù)往磁盤上寫(數(shù)據(jù)在系統(tǒng)內(nèi)存的緩沖區(qū)中)。

（4）操作系統(tǒng)將緩沖區(qū)中的數(shù)據(jù)轉(zhuǎn)移到磁盤控制器上(數(shù)據(jù)在磁盤緩存中)。

（5）磁盤控制器將數(shù)據(jù)寫到磁盤的物理介質(zhì)中(數(shù)據(jù)真正落到磁盤上)。

這5個過程是在理想條件下一個正常的保存流程，但是在大多數(shù)情況下，我們的機器等等都會有各種各樣的故障，這里劃分了兩種情況：

（1）Redis數(shù)據(jù)庫發(fā)生故障，只要在上面的第三步執(zhí)行完畢，那么就可以持久化保存，剩下的兩步由操作系統(tǒng)替我們完成。

（2）操作系統(tǒng)發(fā)生故障，必須上面5步都完成才可以。

在這里只考慮了保存的過程可能發(fā)生的故障，其實保存的數(shù)據(jù)也有可能發(fā)生損壞，需要一定的恢復(fù)機制，不過在這里就不再延伸了。現(xiàn)在主要考慮的是redis如何來實現(xiàn)上面5個保存磁盤的步驟。它提供了兩種策略機制，也就是RDB和AOF。

二、RDB機制

RDB其實就是把數(shù)據(jù)以快照的形式保存在磁盤上。什么是快照呢，你可以理解成把當(dāng)前時刻的數(shù)據(jù)拍成一張照片保存下來。

RDB持久化是指在指定的時間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫入磁盤。也是默認的持久化方式，這種方式是就是將內(nèi)存中數(shù)據(jù)以快照的方式寫入到二進制文件中,默認的文件名為dump.rdb。

在我們安裝了redis之后，所有的配置都是在redis.conf文件中，里面保存了RDB和AOF兩種持久化機制的各種配置。

既然RDB機制是通過把某個時刻的所有數(shù)據(jù)生成一個快照來保存，那么就應(yīng)該有一種觸發(fā)機制，是實現(xiàn)這個過程。對于RDB來說，提供了三種機制：save、bgsave、自動化。我們分別來看一下

1、save觸發(fā)方式

該命令會阻塞當(dāng)前Redis服務(wù)器，執(zhí)行save命令期間，Redis不能處理其他命令，直到RDB過程完成為止。具體流程如下：

執(zhí)行完成時候如果存在老的RDB文件，就把新的替代掉舊的。我們的客戶端可能都是幾萬或者是幾十萬，這種方式顯然不可取。

2、bgsave觸發(fā)方式

執(zhí)行該命令時，Redis會在后臺異步進行快照操作，快照同時還可以響應(yīng)客戶端請求。具體流程如下：

具體操作是Redis進程執(zhí)行fork操作創(chuàng)建子進程，RDB持久化過程由子進程負責(zé)，完成后自動結(jié)束。阻塞只發(fā)生在fork階段，一般時間很短?；旧?Redis 內(nèi)部所有的RDB操作都是采用 bgsave 命令。

3、自動觸發(fā)

自動觸發(fā)是由我們的配置文件來完成的。在redis.conf配置文件中，里面有如下配置，我們可以去設(shè)置：

①save：這里是用來配置觸發(fā) Redis的 RDB 持久化條件，也就是什么時候?qū)?nèi)存中的數(shù)據(jù)保存到硬盤。比如“save m n”。表示m秒內(nèi)數(shù)據(jù)集存在n次修改時，自動觸發(fā)bgsave。

默認如下配置：

#表示900 秒內(nèi)如果至少有 1 個 key 的值變化，則保存save 900 1#表示300 秒內(nèi)如果至少有 10 個 key 的值變化，則保存save 300 10#表示60 秒內(nèi)如果至少有 10000 個 key 的值變化，則保存save 60 10000

不需要持久化，那么你可以注釋掉所有的 save 行來停用保存功能。

②stop-writes-on-bgsave-error ：默認值為yes。當(dāng)啟用了RDB且最后一次后臺保存數(shù)據(jù)失敗，Redis是否停止接收數(shù)據(jù)。這會讓用戶意識到數(shù)據(jù)沒有正確持久化到磁盤上，否則沒有人會注意到災(zāi)難（disaster）發(fā)生了。如果Redis重啟了，那么又可以重新開始接收數(shù)據(jù)了

③rdbcompression ；默認值是yes。對于存儲到磁盤中的快照，可以設(shè)置是否進行壓縮存儲。

④rdbchecksum ：默認值是yes。在存儲快照后，我們還可以讓redis使用CRC64算法來進行數(shù)據(jù)校驗，但是這樣做會增加大約10%的性能消耗，如果希望獲取到最大的性能提升，可以關(guān)閉此功能。

⑤dbfilename ：設(shè)置快照的文件名，默認是 dump.rdb

⑥dir：設(shè)置快照文件的存放路徑，這個配置項一定是個目錄，而不能是文件名。

我們可以修改這些配置來實現(xiàn)我們想要的效果。因為第三種方式是配置的，所以我們對前兩種進行一個對比：

4、RDB 的優(yōu)勢和劣勢

①、優(yōu)勢

（1）RDB文件緊湊，全量備份，非常適合用于進行備份和災(zāi)難恢復(fù)。

（2）生成RDB文件的時候，redis主進程會fork()一個子進程來處理所有保存工作，主進程不需要進行任何磁盤IO操作。

（3）RDB 在恢復(fù)大數(shù)據(jù)集時的速度比 AOF 的恢復(fù)速度要快。

②、劣勢

RDB快照是一次全量備份，存儲的是內(nèi)存數(shù)據(jù)的二進制序列化形式，存儲上非常緊湊。當(dāng)進行快照持久化時，會開啟一個子進程專門負責(zé)快照持久化，子進程會擁有父進程的內(nèi)存數(shù)據(jù)，父進程修改內(nèi)存子進程不會反應(yīng)出來，所以在快照持久化期間修改的數(shù)據(jù)不會被保存，可能丟失數(shù)據(jù)。

三、AOF機制

全量備份總是耗時的，有時候我們提供一種更加高效的方式AOF，工作機制很簡單，redis會將每一個收到的寫命令都通過write函數(shù)追加到文件中。通俗的理解就是日志記錄。

1、持久化原理

他的原理看下面這張圖：

每當(dāng)有一個寫命令過來時，就直接保存在我們的AOF文件中。

2、文件重寫原理

AOF的方式也同時帶來了另一個問題。持久化文件會變的越來越大。為了壓縮aof的持久化文件。redis提供了bgrewriteaof命令。將內(nèi)存中的數(shù)據(jù)以命令的方式保存到臨時文件中，同時會fork出一條新進程來將文件重寫。

重寫aof文件的操作，并沒有讀取舊的aof文件，而是將整個內(nèi)存中的數(shù)據(jù)庫內(nèi)容用命令的方式重寫了一個新的aof文件，這點和快照有點類似。

3、AOF也有三種觸發(fā)機制

（1）每修改同步always：同步持久化 每次發(fā)生數(shù)據(jù)變更會被立即記錄到磁盤 性能較差但數(shù)據(jù)完整性比較好

（2）每秒同步everysec：異步操作，每秒記錄 如果一秒內(nèi)宕機，有數(shù)據(jù)丟失

（3）不同no：從不同步

4、優(yōu)點

（1）AOF可以更好的保護數(shù)據(jù)不丟失，一般AOF會每隔1秒，通過一個后臺線程執(zhí)行一次fsync操作，最多丟失1秒鐘的數(shù)據(jù)。（2）AOF日志文件沒有任何磁盤尋址的開銷，寫入性能非常高，文件不容易破損。

（3）AOF日志文件即使過大的時候，出現(xiàn)后臺重寫操作，也不會影響客戶端的讀寫。

（4）AOF日志文件的命令通過非?？勺x的方式進行記錄，這個特性非常適合做災(zāi)難性的誤刪除的緊急恢復(fù)。比如某人不小心用flushall命令清空了所有數(shù)據(jù)，只要這個時候后臺rewrite還沒有發(fā)生，那么就可以立即拷貝AOF文件，將最后一條flushall命令給刪了，然后再將該AOF文件放回去，就可以通過恢復(fù)機制，自動恢復(fù)所有數(shù)據(jù)

5、缺點

（1）對于同一份數(shù)據(jù)來說，AOF日志文件通常比RDB數(shù)據(jù)快照文件更大

（2）AOF開啟后，支持的寫QPS會比RDB支持的寫QPS低，因為AOF一般會配置成每秒fsync一次日志文件，當(dāng)然，每秒一次fsync，性能也還是很高的

（3）以前AOF發(fā)生過bug，就是通過AOF記錄的日志，進行數(shù)據(jù)恢復(fù)的時候，沒有恢復(fù)一模一樣的數(shù)據(jù)出來。

四、RDB和AOF到底該如何選擇

選擇的話，兩者加一起才更好。因為兩個持久化機制你明白了，剩下的就是看自己的需求了，需求不同選擇的也不一定，但是通常都是結(jié)合使用。有一張圖可供總結(jié)：

對比了這幾個特性，剩下的就是看自己了。

以上是“redis中RDB和AOP持久化是什么”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注億速云行業(yè)資訊頻道！