redis之所以能支援10W/s的讀寫操作主要是依靠

1、所有資料都在記憶體。

2、單執行緒架構，避免了多執行緒可能產生的競爭為題。

3、使用c語言實現，距離作業系統更近。

4、redis的程式碼經過作者精打細磨及優雅與一身。

5、epoll模型io多路複用，將連線、讀寫、關閉都轉換為事件，不在網路IO上浪費過多的時間

但是所有資料都存放在記憶體中，就帶來一個問題，如果伺服器突然宕機，那麼記憶體中的資料會都丟失，所以需要對記憶體中的資料進行持久化處理，把記憶體中的資料儲存在磁碟上，這樣伺服器在重啟後redis就可以通過持久化在磁碟上的備份進行資料恢復。

redis支援兩種持久化機制：RDB和AOF，下面將對這兩種持久化機制進行介紹。

RDB：

即把當前redis記憶體中的資料生成快照儲存到硬碟，也稱作snapshot機制。

對應命令save和bgsave：

save：會阻塞redis主執行緒直到RDB過程結束，記憶體佔用越大的redis例項阻塞的時間就越久，由於redis讀寫操作都是通過主執行緒完成的，也就意味著在阻塞期間redis不能進行讀寫操作，不推薦使用。

bgsave：即在後臺執行，RDB過程期間不會阻塞redis，原理是通過fork出一個子執行緒，由子執行緒完成RDB操作，但是在fork出子執行緒的階段會阻塞redis主執行緒。如下圖所示

除了手動觸發bgsave之外，還有以下自動觸發bgsave的操作：

1、save配置項：“save m n”，表示m秒內n個鍵被修改時自動觸發bgsave

2、主從模式下從節點需要全量複製主節點的資料，主節點會自動觸發bgsave生成RDB檔案，通過網路傳輸給從節點

3、執行debug reload命令重新載入redis時

4、執行shutdown命令時如果沒有開啟AOF持久化機制則自動執行bgsave

RDB檔案存放目錄可以通過dir配置項進行指定，檔名可以通過dbfilename配置項指定，也可以通過客戶端執行config set {dir}， config set dbfilename {filename}進行執行期動態指定

redis預設會使用LZF演算法對生成的RDB檔案進行壓縮，減少磁碟空間的佔用量，可以通過命令config set rdbcompression {yes|no}關閉或開啟，預設開啟。

如果redis在生成RDB檔案時伺服器宕機，則有可能生成的RDB檔案不完整，redis在載入RDB檔案時會對檔案進行校驗，如果RBD檔案損壞則會拒絕啟動並列印日誌，此時可以使用redis-check-dump工具檢測RDB檔案。

RDB機制的優缺點：

優點：

1、RDB檔案壓縮後佔用硬碟空間十分小，代表redis在某個時間點上的資料快照，適合用於備份及全量複製等。

2、redis載入RDB檔案恢復資料的速度遠遠快於AOF

缺點：

1、實時性低，無法做到實時/秒級持久化，且每次執行bgsave都需要fork出子執行緒，屬於重量級操作，頻繁執行bgsave系統資源開銷較大。

2、老版本redis無法相容新版的RDB格式