免费视频淫片aa毛片_日韩高清在线亚洲专区vr_日韩大片免费观看视频播放_亚洲欧美国产精品完整版

Redis 一共有 2 種持久化方式，分別是 RDB 和 AOF，下面我來(lái)詳細(xì)介紹兩種方式在各個(gè)過(guò)程所做的事情，特點(diǎn)等等。

1. RDB 持久化

RDB 持久化是 Redis 默認(rèn)的持久化方式。

它所生成的 RDB 文件是一個(gè)壓縮的二進(jìn)制文件，通過(guò)該文件可以還原生成 RDB 文件時(shí)的數(shù)據(jù)庫(kù)狀態(tài)

PS：數(shù)據(jù)庫(kù)狀態(tài)是指 Redis 服務(wù)器的非空數(shù)據(jù)庫(kù)以及他們鍵值對(duì)的統(tǒng)稱

有兩個(gè)命令可以生成 RDB 文件，一個(gè)是 SAVE、另一個(gè)是 BGSAVE。

兩者的區(qū)別在于：前者會(huì)阻塞 Redis 服務(wù)器進(jìn)程，直到 RDB 文件創(chuàng)建完畢為止。  

而在服務(wù)器進(jìn)程阻塞期間，服務(wù)器是不能處理任何命令請(qǐng)求的。

后者則不會(huì)阻塞服務(wù)器進(jìn)程，因?yàn)槭峭ㄟ^(guò) fork 一個(gè)子進(jìn)程，并讓其去創(chuàng)建 RDB 文件，而服務(wù)器進(jìn)程（父進(jìn)程）繼續(xù)則繼續(xù)處理命令請(qǐng)求。

當(dāng)寫(xiě)完數(shù)據(jù)庫(kù)狀態(tài)后，新 RDB 文件就會(huì)原子地替換舊的 RDB 文件。

此處小提問(wèn)：如果在執(zhí)行 BGSAVE 期間，客戶端發(fā)送 SAVE、BGSAVE 或 BGREWRITEAOF 命令給服務(wù)端，服務(wù)端會(huì)如何處理呢？

答案：在執(zhí)行 BGSAVE 期間，上述三個(gè)命令都不會(huì)被執(zhí)行。    

詳細(xì)原因：前兩個(gè)會(huì)被直接拒絕，原因是為了避免父子進(jìn)程同時(shí)執(zhí)行兩個(gè) rdbSave 調(diào)用，防止產(chǎn)生競(jìng)爭(zhēng)條件。  

而 BGREWRITEAOF 命令則是會(huì)被延遲到 BGSAVE 命令執(zhí)行之后再執(zhí)行。    

但如果是 BGREWRITEAOF 命令正在執(zhí)行，此時(shí)客戶端發(fā)送 BGSAVE 命令則會(huì)被拒絕。    

因?yàn)?BGREWRITEAOF 和 BGSAVE 都是由子進(jìn)程執(zhí)行的，所以在操作方面沒(méi)有沖突的地方，不能同時(shí)執(zhí)行的原因是性能上的考慮——并發(fā)出兩個(gè)子進(jìn)程，并且這兩個(gè)子進(jìn)程都會(huì)同時(shí)執(zhí)行大量 io（磁盤(pán)寫(xiě)入）操作

1.2 RDB 文件的載入

RDB 文件的載入是在服務(wù)器啟動(dòng)時(shí)自動(dòng)執(zhí)行的，所以沒(méi)有用于載入的命令，期間阻塞主進(jìn)程。

只要沒(méi)有開(kāi)啟 AOF 持久化功能，在啟動(dòng)時(shí)檢測(cè)到有 RDB 文件，就會(huì)自動(dòng)載入。

當(dāng)服務(wù)器有開(kāi)啟 AOF 持久化功能時(shí)，服務(wù)器將會(huì)優(yōu)先使用 AOF 文件來(lái)還原數(shù)據(jù)庫(kù)狀態(tài)。原因是 AOF 文件的更新頻率通常比 RDB 文件的更新頻率高。

1.3 自動(dòng)間隔性保存 

對(duì)于 RDB 持久化而言，我們一般都會(huì)使用 BGSAVE 來(lái)持久化，畢竟它不會(huì)阻塞服務(wù)器進(jìn)程。

在 Redis 的配置文件，有提供設(shè)置服務(wù)器每隔多久時(shí)間來(lái)執(zhí)行 BGSAVE 命令。

Redis 默認(rèn)是如下配置：  

save 900 1      // 900 秒內(nèi)，對(duì)數(shù)據(jù)庫(kù)至少修改 1 次。下面同理    

save 300 10     

save 60 10000       

只要滿足其中一種情況，服務(wù)器就會(huì)執(zhí)行 BGSAVE 命令。

2. AOF 持久化

我們從上面的介紹知道，RDB 持久化通過(guò)保存數(shù)據(jù)庫(kù)狀態(tài)來(lái)持久化。而 AOF 與之不同，它是通過(guò)保存對(duì)數(shù)據(jù)庫(kù)的寫(xiě)命令來(lái)記錄數(shù)據(jù)庫(kù)狀態(tài)。

比如執(zhí)行了 set key 123,Redis 就會(huì)將這條寫(xiě)命令保存到 AOF 文件中。

在服務(wù)器下次啟動(dòng)時(shí)，就可以通過(guò)載入和執(zhí)行 AOF 文件中保存的命令，來(lái)還原服務(wù)器關(guān)閉前的數(shù)據(jù)庫(kù)狀態(tài)了。

總體流程和 RDB 持久化一樣 —— 都是創(chuàng)建一個(gè) xxx 文件、在服務(wù)器下次啟動(dòng)時(shí)就載入這個(gè)文件來(lái)還原數(shù)據(jù)

那么，AOF 持久化具體是怎么實(shí)現(xiàn)的呢？

AOF 持久化功能的實(shí)現(xiàn)可以分為 3 個(gè)步驟：命令追加、文件寫(xiě)入、文件同步

其中命令追加很好理解，就是將寫(xiě)命令追加到 AOF 緩沖區(qū)的末尾。

那文件寫(xiě)入和文件同步怎么理解呢？剛開(kāi)始我也一臉懵逼，終于在網(wǎng)上找到了答案，參考見(jiàn)文末，有興趣的讀者可以去看看。

先不賣(mài)關(guān)子了，簡(jiǎn)單一句話解釋就是：前者是緩沖區(qū)內(nèi)容寫(xiě)到 AOF 文件，后者是將 AOF 文件保存到磁盤(pán)。

ok，明白什么意思之后，我們稍微詳細(xì)看下這兩個(gè)東西是什么鬼。

在《Redis設(shè)計(jì)與實(shí)現(xiàn)》中提到，Redis 服務(wù)器進(jìn)程就是一個(gè)事件循環(huán)，這個(gè)循環(huán)中的文件事件（socket 的可讀可寫(xiě)事件）負(fù)責(zé)接收客戶端的命令請(qǐng)求，以及向客戶端發(fā)送命令結(jié)果。

因?yàn)榉?wù)器在處理文件事件時(shí)，可能會(huì)發(fā)生寫(xiě)操作，使得一些內(nèi)容會(huì)被追加到 AOF 緩沖區(qū)末尾。所以，在服務(wù)器每次結(jié)束一個(gè)事件循環(huán)之前 ，都會(huì)調(diào)用 flushAppendOnlyFile 方法。

這個(gè)方法執(zhí)行以下兩個(gè)工作：

• WRITE：根據(jù)條件，將緩沖區(qū)內(nèi)容寫(xiě)入到 AOF 文件。

• SAVE：根據(jù)條件，調(diào)用 fsync 或 fdatasync 函數(shù)，將 AOF 文件保存到磁盤(pán)中。

兩個(gè)步驟都需要根據(jù)一定的條件來(lái)執(zhí)行，而這些條件由 Redis 配置文件中的 appendfsync 選項(xiàng)來(lái)決定的，一共有三個(gè)選擇：

1. appendfsync always：每執(zhí)行一個(gè)命令保存一次

2. appendfsync everysec（默認(rèn)，推薦）：每一秒鐘保存一次

3. appendfsync no：不保存

下面說(shuō)下三個(gè)的區(qū)別：

• appendfsync always：每次執(zhí)行完一個(gè)命令之后， WRITE 和 SAVE 都會(huì)被執(zhí)行  
  

• appendfsync everysec：SAVE 原則上每隔一秒鐘就會(huì)執(zhí)行一次。

• appendfsync no：每次執(zhí)行完一個(gè)命令之后， WRITE 會(huì)執(zhí)行，SAVE 都會(huì)被忽略，只會(huì)在以下任意一種情況中被執(zhí)行：

• Redis 被關(guān)閉

• AOF 功能被關(guān)閉

• 系統(tǒng)的寫(xiě)緩存被刷新（可能是緩存已經(jīng)被寫(xiě)滿，或者定期保存操作被執(zhí)行。完成依賴 OS 的寫(xiě)入，一般為 30 秒左右一次）

而對(duì)于操作特性來(lái)分析的話，則是如下情況：

既然 AOF 持久化是通過(guò)保存寫(xiě)命令到文件的，那隨著時(shí)間的推移，這個(gè) AOF 文件記錄的內(nèi)容就越來(lái)越多，文件體積也就越來(lái)越大，對(duì)其進(jìn)行數(shù)據(jù)還原的時(shí)間也就越來(lái)越久。

針對(duì)這個(gè)問(wèn)題，Redis 提供了 AOF 文件重寫(xiě)功能。

2.2 AOF 重寫(xiě)

通過(guò)該功能來(lái)創(chuàng)建一個(gè)新的 AOF 文件來(lái)代替舊文件。并且兩個(gè)文件所保存的數(shù)據(jù)庫(kù)狀態(tài)一樣，但新文件不會(huì)包含任何冗余命令，所以新文件要比舊文件小得多。

而為什么新文件不會(huì)包含任何冗余命令呢？

那是因?yàn)檫@個(gè)重寫(xiě)功能是通過(guò)讀取服務(wù)器當(dāng)前的數(shù)據(jù)庫(kù)狀態(tài)來(lái)實(shí)現(xiàn)的。雖然叫做「重寫(xiě)」，但實(shí)際上并沒(méi)有對(duì)舊文件進(jìn)行任何讀取修改。

比如舊文件保存了對(duì)某個(gè) key 有 4 個(gè) set 命令，經(jīng)過(guò)重寫(xiě)之后，新文件只會(huì)記錄最后一次對(duì)該 key 的 set 命令。因此說(shuō)新文件不會(huì)包含任何冗余命令

因?yàn)橹貙?xiě)涉及到大量 IO 操作，所以 Redis 是用子進(jìn)程來(lái)實(shí)現(xiàn)這個(gè)功能的，否則將會(huì)阻塞主進(jìn)程。該子進(jìn)程擁有父進(jìn)程的數(shù)據(jù)副本，可以避免在使用鎖的情況下，保證數(shù)據(jù)的安全性。

那么這里又會(huì)存在一個(gè)問(wèn)題，子進(jìn)程在重寫(xiě)過(guò)程中，服務(wù)器還在繼續(xù)處理命令請(qǐng)求，新命令可能會(huì)對(duì)數(shù)據(jù)庫(kù)進(jìn)行修改，這會(huì)導(dǎo)致當(dāng)前數(shù)據(jù)庫(kù)狀態(tài)和重寫(xiě)后的 AOF 文件，所保存的數(shù)據(jù)庫(kù)狀態(tài)不一致。

為了解決這個(gè)問(wèn)題，Redis 設(shè)置了一個(gè) AOF 重寫(xiě)緩沖區(qū)。在子進(jìn)程執(zhí)行 AOF 重寫(xiě)期間，主進(jìn)程需要執(zhí)行以下三個(gè)步驟：

1. 執(zhí)行客戶端的請(qǐng)求命令

2. 將執(zhí)行后的寫(xiě)命令追加到 AOF 緩沖區(qū)

3. 將執(zhí)行后的寫(xiě)命令追加到 AOF 重寫(xiě)緩沖區(qū)

當(dāng)子進(jìn)程結(jié)束重寫(xiě)后，會(huì)向主進(jìn)程發(fā)送一個(gè)信號(hào)，主進(jìn)程接收到之后會(huì)調(diào)用信號(hào)處理函數(shù)執(zhí)行以下步驟：

1. 將 AOF 重寫(xiě)緩沖區(qū)內(nèi)容寫(xiě)入新的 AOF 文件中。此時(shí)新文件所保存的數(shù)據(jù)庫(kù)狀態(tài)就和當(dāng)前數(shù)據(jù)庫(kù)狀態(tài)一致了

2. 對(duì)新文件進(jìn)行改名，原子地覆蓋現(xiàn)有 AOF 文件，完成新舊文件的替換。

當(dāng)函數(shù)執(zhí)行完成后，主進(jìn)程就繼續(xù)處理客戶端命令。

因此，在整個(gè) AOF 重寫(xiě)過(guò)程中，只有在執(zhí)行信號(hào)處理函數(shù)時(shí)才會(huì)阻塞主進(jìn)程，其他時(shí)候都不會(huì)阻塞。

3. 選擇持久化方案的官方建議

通常，如果你要想提供很高的數(shù)據(jù)保障性，那么建議你同時(shí)使用兩種持久化方式。如果你可以接受災(zāi)難帶來(lái)的幾分鐘的數(shù)據(jù)丟失，那么你可以僅使用 RDB。

很多用戶僅使用了 AOF，但是我們建議，既然 RDB 可以時(shí)不時(shí)的給數(shù)據(jù)做個(gè)完整的快照，并且提供更快的重啟，所以最好還是也使用 RDB。

在數(shù)據(jù)恢復(fù)方面：

RDB 的啟動(dòng)時(shí)間會(huì)更短，原因有兩個(gè)：

1. RDB 文件中每一條數(shù)據(jù)只有一條記錄，不會(huì)像 AOF 日志那樣可能有一條數(shù)據(jù)的多次操作記錄。所以每條數(shù)據(jù)只需要寫(xiě)一次就行了。

2. RDB 文件的存儲(chǔ)格式和 Redis 數(shù)據(jù)在內(nèi)存中的編碼格式是一致的，不需要再進(jìn)行數(shù)據(jù)編碼工作，所以在 CPU 消耗上要遠(yuǎn)小于 AOF 日志的加載。  

注意：上面說(shuō)了 RDB 快照的持久化，在進(jìn)行快照的時(shí)候（save），fork 出來(lái)進(jìn)行 dump 操作的子進(jìn)程會(huì)占用與父進(jìn)程一樣的內(nèi)存，真正的 copy-on-write，對(duì)性能的影響和內(nèi)存的耗用都是比較大的。

比如機(jī)器 8G 內(nèi)存，Redis 已經(jīng)使用了 6G 內(nèi)存，這時(shí) save 的話會(huì)再生成 6G，變成 12G，大于系統(tǒng)的 8G。這時(shí)候會(huì)發(fā)生交換；要是虛擬內(nèi)存不夠則會(huì)崩潰，導(dǎo)致數(shù)據(jù)丟失。所以在用 redis 的時(shí)候一定對(duì)系統(tǒng)內(nèi)存做好容量規(guī)劃。    

目前，通常的設(shè)計(jì)思路是利用復(fù)制（Replication）機(jī)制來(lái)彌補(bǔ) aof、snapshot 性能上的不足，達(dá)到了數(shù)據(jù)可持久化。即 Master 上 Snapshot 和 AOF 都不做，來(lái)保證 Master 的讀寫(xiě)性能，而 Slave 上則同時(shí)開(kāi)啟 Snapshot 和 AOF 來(lái)進(jìn)行持久化，保證數(shù)據(jù)的安全性。 

坦白講，我也不知道有多少人能堅(jiān)持看到這里，文章知識(shí)點(diǎn)有點(diǎn)干和雜，這里我?guī)痛蠹液?jiǎn)單總結(jié)一下，做個(gè)回顧：    

• RDB 持久化是 Redis 默認(rèn)持久化方式，通過(guò)保存數(shù)據(jù)庫(kù)鍵值對(duì)來(lái)記錄狀態(tài)來(lái)持久化，由 SAVE 和 BGSAVE 命令來(lái)創(chuàng)建 RDB 文件。前者阻塞 Redis 主進(jìn)程，后者不會(huì)。

• RDB 可以在配置文件設(shè)置每隔多久時(shí)間來(lái)執(zhí)行 BGSAVE 命令

• AOF 通過(guò)追加寫(xiě)命令來(lái)保存當(dāng)前數(shù)據(jù)庫(kù)狀態(tài)。其持久化功能的實(shí)現(xiàn)可以分為 3 個(gè)步驟：命令追加（到 AOF 緩沖區(qū)）、文件寫(xiě)入（緩沖區(qū)內(nèi)容寫(xiě)到 AOF 文件）、文件同步（AOF 文件保存磁盤(pán)）

• 其中文件同步和保存可以通過(guò)配置文件的 appendfsync 選項(xiàng)來(lái)決定

• 為了解決 AOF 文件越來(lái)越大的問(wèn)題，Redis 提供了 AOF 重寫(xiě)功能，并且不會(huì)阻塞主進(jìn)程。

• 為了解決 AOF 重寫(xiě)過(guò)程中，新 AOF 文件所保存的數(shù)據(jù)庫(kù)狀態(tài)和當(dāng)前數(shù)據(jù)庫(kù)狀態(tài)可能不一致的問(wèn)題，Redis 引入了 AOF 重寫(xiě)緩沖區(qū)，用于保存子進(jìn)程在重寫(xiě) AOF 文件期間產(chǎn)生的新的寫(xiě)命令。

• 最后是官方對(duì)于兩種持久化方式選擇的一些建議

參考：  

《redis設(shè)計(jì)與實(shí)現(xiàn)》

https://www.cnblogs.com/zhoujinyi/archive/2013/05/26/3098508.html  

https://redisbook.readthedocs.io/en/latest/internal/aof.html