今天來分享一道比較好的面試題，“Redis中RDB和AOF兩種持久化機制的原理的優(yōu)缺點？”對于這個問題，我們一起看看考察點和比較好的回答吧！

考察點

現(xiàn)在的企業(yè)級開發(fā)中Redis的應用非常廣泛，在面試中Redis幾乎是必問的，因此除了Redis的基礎知識之外，還要學習和了解一些經(jīng)典和難點的題目！那么這個問題就是面試官想考察我們是不是平日里善于積累，仔細思考這方面的知識，同時想看看我們是不是具有這方面的能力！

回答  

關于這個問題，我從以下幾點來回答：

(1) Redis是一個基于Key-Value結構的內(nèi)存數(shù)據(jù)庫，在服務器重啟的時候會丟失內(nèi)存數(shù)據(jù)，所以為了避免Redis故障或者重啟等因素導致數(shù)據(jù)丟失的問題，Redis為我們提供了RDB和AOF兩種持久化機制。

(2) RDB持久化機制：RDB是通過快照的方式來實現(xiàn)持久化的，也就是說會根據(jù)快照的觸發(fā)條件，把內(nèi)存里面的數(shù)據(jù)快照寫入到磁盤，以二進制的壓縮文件進行存儲，如圖所示。bgsave線程觸發(fā)異步快照，會fork()出一個子進程生成RDB文件，在寫完之后，會用來替換舊的RDB文件。

RDB快照的觸發(fā)方式分為異步和同步兩種：

•  執(zhí)行bgsave命令觸發(fā)異步快照
•  執(zhí)行save命令觸發(fā)同步快照，同步快照會阻塞客戶端的執(zhí)行指令。

(3) AOF持久化機制：

AOF持久化是一種近乎實時的方式，把Redis Server執(zhí)行的事務命令進行追加存儲。在使用上往往是根據(jù)redis.conf文件里面的配置，自動觸發(fā)bgsave主從復制的時候觸發(fā)AOF持久化。簡單來說，就是客戶端執(zhí)行一個數(shù)據(jù)變更的操作，Redis Server就會把這個命令追加到AOF緩沖區(qū)的末尾，然后再把緩沖區(qū)的數(shù)據(jù)寫入到磁盤的AOF文件里面，至于最終什么時候真正持久化到磁盤，是根據(jù)刷盤的策略來決定的，刷盤策略可分為異步刷盤和同步刷盤兩類。

AOF存在的問題：因為AOF這種指令追加的方式，會造成AOF文件過大，帶來明顯的IO性能問題，所以Redis針對這種情況提供了AOF重寫機制，也就是說當AOF文件的大小達到某個閾值的時候，就會把這個文件里面相同的指令進行壓縮。

(4) RDB和AOF的優(yōu)缺點：

基于對RDB和AOF的工作原理的理解，我認為RDB和AOF的優(yōu)缺點有兩個：

• RDB是每隔一段時間觸發(fā)持久化，因此數(shù)據(jù)安全性低，AOF可以做到實時持久化，數(shù)據(jù)安全性較高。
• RDB文件默認采用壓縮的方式持久化，AOF存儲的是執(zhí)行指令，所以RDB在數(shù)據(jù)恢復的時候性能比AOF要好。

在我看來，所謂優(yōu)缺點，本質(zhì)上其實是哪種方案更適合當前的應用場景而已，畢竟魚和熊掌不可兼得。

以上就是我對于這個問題的理解。

本文轉(zhuǎn)載自微信公眾號「程序員的故事」，可以通過以下二維碼關注。轉(zhuǎn)載本文請聯(lián)系程序員的故事公眾號。程序員的故事原創(chuàng)文章，遵循CC 4.0 BY-SA版權協(xié)議。