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

考察點(diǎn)

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

回答  

關(guān)于這個(gè)問題，我從以下幾點(diǎn)來回答：

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

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

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

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

(3) AOF持久化機(jī)制：

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

AOF存在的問題：因?yàn)锳OF這種指令追加的方式，會(huì)造成AOF文件過大，帶來明顯的IO性能問題，所以Redis針對這種情況提供了AOF重寫機(jī)制，也就是說當(dāng)AOF文件的大小達(dá)到某個(gè)閾值的時(shí)候，就會(huì)把這個(gè)文件里面相同的指令進(jìn)行壓縮。

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

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

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

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

以上就是我對于這個(gè)問題的理解。

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