Redis數據持久化

Redis是個支持持久化的內存數據庫，redis須要常常將內存中的數據同步到磁盤來保證持久化。

---

一、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 dir
1) "dir"
2) "/usr/local/redis/db"
127.0.0.1:7000>

1.4）優勢：

1.4.1）RDB是個很是緊湊的文件，保存了redis在某個時間點上的數據集，使得咱們能夠經過定時備份RDB文件來實現Redis數據庫備份和災難恢復，也能夠將其傳送到其餘的數據中心用於保存。

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> save
OK
127.0.0.1:7000>

緣由：save操做是在主線程中保存快照的，因爲redis是用一個主線程來處理全部 client的請求，這種方式會阻塞全部client請求。因此不推薦使用。

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

2.1）配置

appendonly yes  
#開啓aof
appendfilename "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 dir
1) "dir"
2) "/usr/local/redis/db"
127.0.0.1:7000>
[root@redis1 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
[root@redis1 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。

三、其它

虛擬內存方式和diskstore方式。：（不建議，並且虛擬內存聽說2.4版本後棄用，diskstore也不經常使用）

相關配置

持久化文件會變的愈來愈大。
vm-enabled yes          
#開啓vm功能
vm-swap-file /tmp/redis.swap   
#交換出來的value保存的文件路徑/tmp/redis.swap
vm-max-memory 1000000  
#redis使用的最大內存上限，超過上限後redis開始交換value到磁盤文件中
vm-page-size 32        
#每一個頁面的大小32個字節
vm-pages 134217728     
#最多使用在文件中使用多少頁面,交換文件的大小 = vm-page-size * vm-pages
vm-max-threads 4       
#用於執行value對象換入換出的工做線程數量，0表示不使用工做線程

---

總結：

一、Redis容許同時開啓AOF和RDB，既保證了數據安全又使得進行備份等操做十分容易。從新啓動Redis後Redis會使用AOF文件來恢復數據，由於AOF方式的持久化可能丟失的數據更少。

二、讀寫分離 經過複製能夠實現讀寫分離以提升服務器的負載能力。在常見的場景中，讀的頻率大於寫，當單機的Redis沒法應付大量的讀請求時（尤爲是較耗資源的請求，好比SORT命令等）能夠經過複製功能創建多個從數據庫，主數據庫只進行寫操做，而從數據庫負責讀操做。

三、從數據庫持久化 持久化一般相對比較耗時，爲了提升性能，能夠經過複製功能創建一個（或若干個）從數據庫，並在從數據庫中啓用持久化，同時在主數據庫禁用持久化。當從數據庫崩潰時重啓後主數據庫會自動將數據同步過來，因此無需擔憂數據丟失。而當主數據庫崩潰時，須要在從數據庫中使用SLAVEOF NO ONE命令將從數據庫提高成主數據庫繼續服務，並在原來的主數據庫啓動後使用SLAVEOF命令將其設置成新的主數據庫的從數據庫，便可將數據同步回來。

若有不妥，歡迎指正！