Redis的多種持久化方式總結

標籤：redis的多種持久化方式總結

話題：Redis的多種持久化方式：

Redis是個支援持久化的記憶體資料庫，redis需要經常將記憶體中的資料同步到磁碟來保證持久化。

1、RDB方式（Snapshotting預設快照方式）：

1.1）配置：

save 900 1       #在900秒(15分鐘)之後，如果至少有1個key發生變化，則dump記憶體快照。save 300 10      #在300秒(5分鐘)之後，如果至少有10個key發生變化，則dump記憶體快照。save 60 10000    #在60秒(1分鐘)之後，如果至少有10000個key發生變化，則dump記憶體快照。

1.2）工作原理：

1.2.1）Redis使用fork函數複製一份當前進程（父進程）的副本（子進程）；

1.2.2）父進程繼續接收並處理用戶端發來的命令，而子進程開始將記憶體中的資料寫入硬碟中的臨時檔案；

1.2.3）當子進程寫入完所有資料後會用該臨時檔案替換舊的RDB檔案，至此一次快照操作完成。

1.3）查看dump.rdb:

127.0.0.1:7000> config get dir1) "dir"2) "/usr/local/redis/db"127.0.0.1:7000>

1.4）優點：

1.4.1）RDB是個非常緊湊的檔案，儲存了redis在某個時間點上的資料集，使得我們可以通過定時備份RDB檔案來實現RedisDatabase Backup和災難恢複，也可以將其傳送到其他的資料中心用於儲存。

1.4.2）RDB可以最大化redis的效能，執行RDB持久化時只需要fork一個子進程，並由子進程進行持久化工作，父進程不需要處理任何磁碟I/O操作。

1.4.3）RDB在恢複大資料集時比AOF要快，啟動效率要高許多。

1.4.4）RDB檔案是經過壓縮（可以配置rdbcompression參數以禁用壓縮節省CPU佔用）的二進位格式，所以佔用的空間會小於記憶體中的資料大小，更加利於傳輸。

1.5）缺點：

1.5.1）每次快照持久化都是將記憶體資料完整寫入到磁碟一次，並不是增量的只同步增資料。如果資料量大的話，而且寫操作比較多，必然會引起大量的磁碟io操作，可能會嚴重影響效能。

1.5.2）快照方式是在一定間隔時間做一次的，所以如果redis意外down掉的話，就會丟失最後一次快照後的所有修改，有一些資料丟失的風險。

1.5.2）client的save或者bgsave命令通知redis做一次快照持久化不推薦。

127.0.0.1:7000> saveOK127.0.0.1:7000>

原因：save操作是在主線程中儲存快照的，由於redis是用一個主線程來處理所有 client的請求，這種方式會阻塞所有client請求。所以不推薦使用。

2、Append-only file（縮寫aof）的方式：

2.1）配置

appendonly yes  #開啟aofappendfilename "appendonly.aof"  #名字# appendfsync always   # 每次執行寫入都會執行同步，最安全也最慢appendfsync everysec   # 每秒執行一次同步操作# appendfsync no #不主動進行同步操作，而是完全交由作業系統來做（即每30秒一次),最快也最不安全。#配置寫入AOF檔案後，要求系統重新整理硬碟緩衝的機制auto-aof-rewrite-percentage 100  # 當目前的AOF檔案大小超過上一次重寫時的AOF檔案大小的百分之多少時會再次進行重寫，如果之前沒有重寫過，則以啟動時的AOF檔案大小為依據auto-aof-rewrite-min-size 64mb   # 允許重寫的最小AOF檔案大小

2.2）工作原理：

2.2.1）redis調用fork ，現在有父子兩個進程

2.2.2）子進程根據記憶體中的資料庫快照集，往臨時檔案中寫入重建資料庫狀態的命令

2.2.3）父進程繼續處理client請求，除了把寫命令寫入到原來的aof檔案中。同時把收到的寫命令緩衝起來。這樣就能保證如果子進程重寫失敗的話並不會出問題。

2.2.4.）當子進程把快照內容寫入已命令方式寫到臨時檔案中後，子進程發訊號通知父進程。然後父進程把緩衝的寫命令也寫入到臨時檔案。

2.2.5）現在父進程可以使用臨時檔案替換老的aof檔案，並重新命名，後面收到的寫命令也開始往新的aof檔案中追加。

2.3）查看aof

127.0.0.1:7000> config get dir1) "dir"2) "/usr/local/redis/db"127.0.0.1:7000>[[email protected] db]# ll總用量 8-rw-r--r-- 1 root root 146 2月   1 08:36 appendonly.aof-rw-r--r-- 1 root root  74 2月   1 09:20 dump.rdb[[email protected] db]#

2.4）優點：

2.4.1）該機制可以帶來更高的資料安全性，即資料持久性。

2.4.2）由於該機制對記錄檔的寫入操作採用的是append模式，因此在寫入過程中即使出現宕機現象，也不會破壞記錄檔中已經存在的內容。然而如果我們本次操作只是寫入了一半資料就出現了系統崩潰問題，不用擔心，在Redis下一次啟動之前，我們可以通過redis-check-aof工具來協助我們解決資料一致性的問題。

2.4.3）如果日誌過大，Redis可以自動啟用rewrite機制。即Redis以append模式不斷的將修改資料寫入到老的磁碟檔案中，同時Redis還會建立一個新的檔案用於記錄此期間有哪些修改命令被執行。因此在進行rewrite切換時可以更好的保證資料安全性。

2.4.4） AOF包含一個格式清晰、易於理解的記錄檔用於記錄所有的修改操作。事實上，也可以通過該檔案完成資料的重建。

2.5：缺點：

2.5.1）對於相同數量的資料集而言，AOF檔案通常要大於RDB檔案，持久化檔案會變的越來越大。

2.5.2） 根據同步策略的不同，AOF在運行效率上往往會慢於RDB。

3、其它

虛擬記憶體方式和diskstore方式。：（不建議，而且虛擬記憶體據說2.4版本後棄用，diskstore也不常用）

相關配置

持久化檔案會變的越來越大。vm-enabled yes          #開啟vm功能vm-swap-file /tmp/redis.swap   #交換出來的value儲存的檔案路徑/tmp/redis.swapvm-max-memory 1000000  #redis使用的最大記憶體上限，超過上限後redis開始交換value到磁碟檔案中vm-page-size 32        #每個頁面的大小32個位元組vm-pages 134217728     #最多使用在檔案中使用多少頁面,分頁檔的大小 = vm-page-size * vm-pagesvm-max-threads 4       #用於執行value對象換入換出的背景工作執行緒數量，0表示不使用背景工作執行緒

總結：

1、Redis允許同時開啟AOF和RDB，既保證了資料安全又使得進行備份等操作十分容易。重新啟動Redis後Redis會使用AOF檔案來恢複資料，因為AOF方式的持久化可能丟失的資料更少。

2、讀寫分離 通過複製可以實現讀寫分離以提高伺服器的負載能力。在常見的情境中，讀的頻率大於寫，當單機的Redis無法應付大量的讀請求時（尤其是較耗資源的請求，比如SORT命令等）可以通過複製功能建立多個從資料庫，主要資料庫只進行寫操作，而從資料庫負責讀操作。

3、從資料庫持久化 持久化通常相對比較耗時，為了提高效能，可以通過複製功能建立一個（或若干個）從資料庫，並在從資料庫中啟用持久化，同時在主要資料庫禁用持久化。當從資料庫崩潰時重啟後主要資料庫會自動將資料同步過來，所以無需擔心資料丟失。而當主要資料庫崩潰時，需要在從資料庫中使用SLAVEOF NO ONE命令將從資料庫提升成主要資料庫繼續服務，並在原來的主要資料庫啟動後使用SLAVEOF命令將其設定成新的主要資料庫的從資料庫，即可將資料同步回來。

本文出自 “永不放棄! 任志遠” 部落格，轉載請與作者聯絡！

Redis的多種持久化方式總結