持久化的目的主要是做災難恢復，資料恢復。由於redis的資料全都放在記憶體裡面，如果redis掛了，沒有配置持久化的話，重啟的時候資料會全部丟失。
突然間，大量的請求過來，快取全都無法命中，造成快取雪崩，mysql無法承載大量的請求，造成整個系統崩潰。如果把redis持久化做好，即使redis故障了，也能夠立即重啟，對外提供服務。
redis持久化分為兩種：rdb的優缺點：
一旦採用該方式，那麼你的整個redis資料庫將只包含乙個檔案，這對於檔案備份而言是非常完美的。比如，你可能打算每個小時歸檔一次最近24小時的數 據，同時還要每天歸檔一次最近30天的資料。通過這樣的備份策略，一旦系統出現災難性故障，我們可以非常容易的進行恢復。
相對於 aof 持久化機制來說，直接基於 rdb 資料檔案來重啟和恢復 redis 程序，更加快速。
rdb 對 redis 對外提供的讀寫服務，影響非常小，可以讓 redis 保持高效能，因為 redis 主程序只需要 fork 乙個子程序，讓子程序執行磁碟 io 操作來進行 rdb 持久化即可。
對於災難恢復而言，rdb是非常不錯的選擇。因為我們可以非常輕鬆的將乙個單獨的檔案壓縮後再轉移到其它儲存介質上。
如果想要在 redis 故障時，盡可能少的丟失資料，那麼 rdb 沒有 aof 好。一般來說，rdb 資料快照檔案，都是每隔 5 分鐘，或者更長時間生成一次，這個時候就得接受一旦 redis 程序宕機，那麼會丟失最近 5 分鐘的資料。
rdb 每次在 fork 子程序來執行 rdb 快照資料檔案生成的時候，如果資料檔案特別大，可能會導致對客戶端提供的服務暫停數毫秒，或者甚至數秒。
rdb和aof如何選擇？
不要僅僅使用 rdb，因為那樣會導致你丟失很多資料；
也不要僅僅使用 aof，因為那樣有兩個問題：第一，你通過 aof 做冷備，沒有 rdb 做冷備來的恢復速度更快；第二，rdb 每次簡單粗暴生成資料快照，更加健壯，可以避免 aof 這種複雜的備份和恢復機制的 bug；
redis 支援同時開啟開啟兩種持久化方式，我們可以綜合使用 aof 和 rdb 兩種持久化機制，用 aof 來保證資料不丟失，作為資料恢復的第一選擇; 用 rdb 來做不同程度的冷備，在 aof 檔案都丟失或損壞不可用的時候，還可以使用 rdb 來進行快速的資料恢復。
Redis 持久化有幾種方式？
redis 持久化的兩種方式 rdb rdb 持久化機制，是對 redis 中的資料執行週期性的持久化。rdb 優缺點 rdb 會生成多個資料檔案，每個資料檔案都代表了某乙個時刻中 redis 的資料，這種多個資料檔案的方式，非常適合做冷備，可以將這種完整的資料檔案傳送到一些遠端的安全儲存上去，比如...
Redis持久化方式
一 前言 持久化主要是做災難恢復 資料恢復，也可以歸類到高可用的乙個環節中去，比如你 redis 整個掛了，然後 redis 就不可用了，你要做的事情就是讓 redis 變得可用，盡快變得可用。重啟 redis，盡快讓它堆外提供服務，如果沒做資料備份，這時候 redis 啟動了，也不可用啊，資料都沒...
Redis持久化方式
rdb全稱redis database，在指定的時間間隔內將記憶體中的資料集快照寫入磁碟，也就是行話講的snapshot快照，它恢復時直接將快照檔案直接讀到記憶體裡 在預設情況下，redis 將記憶體資料庫快照儲存在名字為 dump.rdb 的二進位制檔案中，有手動觸發和自動觸發兩種方式。手動觸發 ...