在運行的過程中，redis是以數據結構的形式將數據維持在內存中的，爲了讓這些數據在redis重啓之後仍然可以使用，這時候就需要持久化。就是我們把數據存儲在redis關閉後不會丟失的設備中了，通常是硬盤。
Redis的持久化有2種方式，快照和日誌。
這一節我們介紹的是rdb的工作原理：每個N分鐘或者N次寫操作後，從內存dump數據形成rdb文件，也是二進制文件。這是一種快照的方式。rdb方式是redis默認的一種方式。當我們在斷點或者重啓redis之後，那麼就會幫助我們回覆數據。但是當我們的redis數據庫持續寫入的時候，我們是fork出了一個子進程，在子進程中循環所有的數據，將數據寫成爲一個RDB文件。
生成rdb方式1
使用rdb的配置：
時長和修改的頻率，相互的彌補。/
save 900 1 // 900內,有1條寫入,則產生快照
save 300 1000 // 如果300秒內有1000次寫入,則產生快照
save 60 10000 // 如果60秒內有10000次寫入,則產生快照
(這3個選項都屏蔽,則rdb禁用，因爲找不到導出規則了，所以停止了。)
時間滿了之後，就會導出。
stop-writes-on-bgsave-error yes // 後臺備份進程出錯時,主進程停不停止寫入，停止也如
rdbcompression yes // 導出的rdb文件是否壓縮
Rdbchecksum yes // 導入rbd恢復時數據時,要不要檢驗rdb的完整性
dbfilename dump.rdb //導出來的rdb文件名
dir ./ //rdb的放置路徑
缺陷：
每次做一個快照是在有足夠的積累之後是N分鐘或者N次操作之後，那麼這樣，當在兩個保存點之間斷電的時候會丟失1-N分鐘或者1--N次的數據的數據。這個問題我們可以使用AOF的方式來彌補。
優勢：
rdb是從內存中導出的一個二進制的內存塊，這個文件在回覆的時候也是很快的。
注意：
當我們使用6379的rdb文件將數據恢復到另外一個6380的redis進程中的時候，我們在賦值6379的rdb到6380那麼如果6379的redis進程運行的時候，rdb處於打開狀態，此時複製文件，佔用同樣的句柄。所以這樣看是複製了兩份文件，但是佔用了同一個句柄，這樣複製的rdb6380是沒有複製過來數據。,無法恢復數據。
方式2：
cient 也可以使用save或者bgsave命令通知redis做一次快照持久化。save操作是在主線程中保存快照的，由於redis是用一個主線程來處理所有 client的請求，這種方式會阻塞所有client請求。所以不推薦使用。另一點需要注意的是，每次快照持久化都是將內存數據完整寫入到磁盤一次，並不 是增量的只同步髒數據。如果數據量大的話，而且寫操作比較多，必然會引起大量的磁盤io操作，可能會嚴重影響性能。
解決方案：如果我們有主從複製的話，使用從服務器來分擔這種大量的IO操作。