阿里JAVA面試題剖析：Redis 的持久化有哪幾種方式？不一樣的持久化機制都有什麼優缺點？持久化機制具體底層是如何實現的？

面試原題

redis 的持久化有哪幾種方式？不一樣的持久化機制都有什麼優缺點？持久化機制具體底層是如何實現的？

面試官心理分析

redis 若是僅僅只是將數據緩存在內存裏面，若是 redis 宕機了再重啓，內存裏的數據就所有都弄丟了啊。你必須得用 redis 的持久化機制，將數據寫入內存的同時，異步的慢慢的將數據寫入磁盤文件裏，進行持久化。

若是 redis 宕機重啓，自動從磁盤上加載以前持久化的一些數據就能夠了，也許會丟失少量數據，可是至少不會將全部數據都弄丟。

這個其實同樣，針對的都是 redis 的生產環境可能遇到的一些問題，就是 redis 要是掛了再重啓，內存裏的數據不就全丟了？能不能重啓的時候把數據給恢復了？

面試題剖析

持久化主要是作災難恢復、數據恢復，也能夠歸類到高可用的一個環節中去，好比你 redis 整個掛了，而後 redis 就不可用了，你要作的事情就是讓 redis 變得可用，儘快變得可用。

重啓 redis，儘快讓它堆外提供服務，若是沒作數據備份，這時候 redis 啓動了，也不可用啊，數據都沒了。

極可能說，大量的請求過來，緩存所有沒法命中，在 redis 里根本找不到數據，這個時候就死定了，出現緩存雪崩問題。全部請求沒有在 redis 命中，就會去 mysql 數據庫這種數據源頭中去找，一會兒 mysql 承接高併發，而後就掛了...

若是你把 redis 持久化作好，備份和恢復方案作到企業級的程度，那麼即便你的 redis 故障了，也能夠經過備份數據，快速恢復，一旦恢復當即對外提供服務。

redis 持久化的兩種方式

RDB：RDB 持久化機制，是對 redis 中的數據執行週期性的持久化。

AOF：AOF 機制對每條寫入命令做爲日誌，以 append-only 的模式寫入一個日誌文件中，在 redis 重啓的時候，能夠經過回放 AOF 日誌中的寫入指令來從新構建整個數據集。

經過 RDB 或 AOF，均可以將 redis 內存中的數據給持久化到磁盤上面來，而後能夠將這些數據備份到別的地方去，好比說阿里雲等雲服務。

若是 redis 掛了，服務器上的內存和磁盤上的數據都丟了，能夠從雲服務上拷貝回來以前的數據，放到指定的目錄中，而後從新啓動 redis，redis 就會自動根據持久化數據文件中的數據，去恢復內存中的數據，繼續對外提供服務。

若是同時使用 RDB 和 AOF 兩種持久化機制，那麼在 redis 重啓的時候，會使用 AOF 來從新構建數據，由於 AOF 中的數據更加完整。

RDB 優缺點

RDB會生成多個數據文件，每一個數據文件都表明了某一個時刻中 redis 的數據，這種多個數據文件的方式，很是適合作冷備，能夠將這種完整的數據文件發送到一些遠程的安全存儲上去，好比說 Amazon 的 S3 雲服務上去，在國內能夠是阿里雲的 ODPS 分佈式存儲上，以預約好的備份策略來按期備份redis中的數據。

RDB 對 redis 對外提供的讀寫服務，影響很是小，可讓 redis 保持高性能，由於 redis 主進程只須要 fork 一個子進程，讓子進程執行磁盤 IO 操做來進行 RDB 持久化便可。

相對於 AOF 持久化機制來講，直接基於 RDB 數據文件來重啓和恢復 redis 進程，更加快速。

若是想要在 redis 故障時，儘量少的丟失數據，那麼 RDB 沒有 AOF 好。通常來講，RDB 數據快照文件，都是每隔 5 分鐘，或者更長時間生成一次，這個時候就得接受一旦 redis 進程宕機，那麼會丟失最近 5 分鐘的數據。

RDB 每次在 fork 子進程來執行 RDB 快照數據文件生成的時候，若是數據文件特別大，可能會致使對客戶端提供的服務暫停數毫秒，或者甚至數秒。

AOF 優缺點

AOF 能夠更好的保護數據不丟失，通常 AOF 會每隔 1 秒，經過一個後臺線程執行一次fsync操做，最多丟失 1 秒鐘的數據。

AOF 日誌文件以 append-only 模式寫入，因此沒有任何磁盤尋址的開銷，寫入性能很是高，並且文件不容易破損，即便文件尾部破損，也很容易修復。

AOF 日誌文件即便過大的時候，出現後臺重寫操做，也不會影響客戶端的讀寫。由於在 rewrite log 的時候，會對其中的指導進行壓縮，建立出一份須要恢復數據的最小日誌出來。再建立新日誌文件的時候，老的日誌文件仍是照常寫入。當新的 merge 後的日誌文件 ready 的時候，再交換新老日誌文件便可。

AOF 日誌文件的命令經過很是可讀的方式進行記錄，這個特性很是適合作災難性的誤刪除的緊急恢復。好比某人不當心用 flushall 命令清空了全部數據，只要這個時候後臺 rewrite 尚未發生，那麼就能夠當即拷貝 AOF 文件，將最後一條 flushall 命令給刪了，而後再將該 AOF 文件放回去，就能夠經過恢復機制，自動恢復全部數據。

對於同一份數據來講，AOF 日誌文件一般比 RDB 數據快照文件更大。

AOF 開啓後，支持的寫 QPS 會比 RDB 支持的寫 QPS 低，由於 AOF 通常會配置成每秒 fsync 一第二天志文件，固然，每秒一次 fsync，性能也仍是很高的。（若是實時寫入，那麼 QPS 會大降，redis 性能會大大下降）

之前 AOF 發生過 bug，就是經過 AOF 記錄的日誌，進行數據恢復的時候，沒有恢復如出一轍的數據出來。因此說，相似 AOF 這種較爲複雜的基於命令日誌/merge/回放的方式，比基於 RDB 每次持久化一份完整的數據快照文件的方式，更加脆弱一些，容易有 bug。不過 AOF 就是爲了不 rewrite 過程致使的 bug，所以每次 rewrite 並非基於舊的指令日誌進行 merge 的，而是基於當時內存中的數據進行指令的從新構建，這樣健壯性會好不少。

RDB和AOF到底該如何選擇

不要僅僅使用 RDB，由於那樣會致使你丟失不少數據；

也不要僅僅使用 AOF，由於那樣有兩個問題：第一，你經過 AOF 作冷備，沒有 RDB 作冷備來的恢復速度更快；第二，RDB 每次簡單粗暴生成數據快照，更加健壯，能夠避免 AOF 這種複雜的備份和恢復機制的 bug；

redis 支持同時開啓開啓兩種持久化方式，咱們能夠綜合使用 AOF 和 RDB 兩種持久化機制，用 AOF 來保證數據不丟失，做爲數據恢復的第一選擇; 用 RDB 來作不一樣程度的冷備，在 AOF 文件都丟失或損壞不可用的時候，還可使用 RDB 來進行快速的數據恢復。

---

本文的重點是你有沒有收穫與成長，其他的都不重要，但願讀者們能謹記這一點。同時我通過多年的收藏目前也算收集到了一套完整的學習資料，包括但不限於：分佈式架構、高可擴展、高性能、高併發、Jvm性能調優、Spring，MyBatis，Nginx源碼分析，Redis，ActiveMQ、、Mycat、Netty、Kafka、Mysql、Zookeeper、Tomcat、Docker、Dubbo、Nginx等多個知識點高級進階乾貨，但願對想成爲架構師的朋友有必定的參考和幫助

須要更詳細架構師技能思惟導圖和如下資料的能夠加一下技術交流分享羣：「708 701 457」免費獲取