Redis持久化方式的選擇

本文將介紹Redis持久化的兩種方式：快照持久化和AOF持久化，並對兩種方法進行分析和對比，方便在實際中作出選擇。

持久化

什麼是持久化

Redis全部數據保存在內存中，對數據的更新將異步地保存到磁盤上，使得數據在Redis重啓以後仍然存在。這麼作這有什麼實際意義呢？將數據存儲到硬盤是爲了之後能夠重用數據，將數據進行備份，能夠在系統故障的時候從備份進行恢復。還有一點，存儲在Redis裏面的數據多是通過複雜運算而得出的結果，把這些數據進行存儲，方便後續的使用，以達到「空間換時間」的效果。

持久化的實現方式

Redis提供了兩種不一樣的持久化方法將數據保存到硬盤裏面。

快照持久化：將Redis某一時刻存在的全部數據都寫入硬盤。

AOF持久化：AOF的全稱叫append-only file，中文意思是隻追加文件。當使用AOF持久化方式的時候，Redis執行寫命令的時候，將被執行的寫命令複製到硬盤裏面，說的通俗一點就是寫日誌。

快照持久化

什麼是快照持久化

Redis經過建立快照來得到存儲在內存裏面的數據在某個時間節點上的副本。

觸發機制-主要三種方式

1. save（同步）
2. bgsave（異步）
3. 自動

save命令：客戶端向Redis發送save命令來建立一個快照文件。

執行save命令的時候，若是存在老的快照文件，新的將會替換老的。

bgsave命令：客戶端向Redis發送bgsave命令，Redis調用fork建立一個子進程，而後子進程負責將快照寫入硬盤，而父進程則繼續處理命令請求。

save命令和bgsave命令對比：

命令	save	bgsave
IO類型	同步	異步
是否阻塞	是	是
複雜度	O(n)	O(n)
優勢	不會消耗額外內存	不阻塞客戶端命令
缺點	阻塞客戶端命令	須要fork，消耗內存

自動生成：經過配置，知足任何一個條件就會建立快照文件。

快照持久化選項：

多久執行一次自動快照操做，60s以內有1000次操做寫入時執行
save 60 1000
建立快照失敗後是否仍然繼續執行寫命令
stop-writes-on-bgsave-error no
是否對快照文件進行壓縮
rdbcompression yes
命名硬盤上的快照文件
dbfilename dump.rdb

最佳配置：

dbfilename dump-${port}.rdb
dir /bigdiskpath
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes

AOF持久化

快照持久化現存問題

耗時、耗性能：經過bgsave命令進行持久化的的時候，須要fork一個子進程，若是數據量很大的話，須要的內存也會相應的變大，內存的佔用會致使Redis性能下降。

不可控、丟失數據：舉個例子，上一次建立快照是11:00開始建立並建立成功。若是Redis在12:00開始建立新的快照，若是系統在未完成建立快照以前崩潰，11:00-12:00寫入的數據將會丟失；若是系統在快照建立完成以後崩潰，那麼12:00以後，建立快照的過程當中的數據將會丟失。

什麼是AOF

AOF持久化將被執行的寫命令寫到AOF文件的末尾，以達到記錄數據的目的。Redis只要從頭至尾從新執行一次AOF全部的命令就能夠恢復數據。

AOF三種策略

always：每條Redis寫命令都同步寫入硬盤。

everysec：每秒執行一次同步，將多個命令寫入硬盤。

no：由操做系統決定什麼時候同步。

三種策略對比：生產環境中須要根據實際的需求進行選擇。

命令	always	everysec	no
優勢	不丟失數據	每秒一次fsync	不用管
缺點	IO開銷較大，通常的SATA盤只有幾百TPS	丟1s數據	不可控

AOF重寫

隨着Redis的運行，被執行的寫命令不斷同步到AOF文件中，AOF文件的體積愈來愈大，極端狀況將會佔滿全部的硬盤空間。若是AOF文件體積過大，還原的過程也會至關耗時。爲了解決AOF文件不斷膨脹的問題，須要移除AOF文件中的冗餘命令來重寫AOF。

原生AOF	AOF重寫
set hello world set hello java set hello redis incr counter inct counter rpush mylist a rpush mylist b rpush mylist c 過時數據	set hello redis set counter 2 rpush mylist a b c

 

AOF重寫的兩種實現方式：

• bgrewriteaof命令

bgrewriteaof命令和bgsave命令的工做原理類似：Redis建立一個子進程，而後由子進程負責對AOF文件進行重寫。

• AOF重寫配置

配置參數說明：

名稱	含義
auto-aof-rewrite-min-size	AOF文件重寫須要的尺寸
auto-aof-rewrite-percentage	AOF文件增加率

 

具體配置：

appendonly yes
appendfilename "appendonly-${port}.aof"
appendfsync everysc
dir /bigdiskpath
no-appendfsync-on-rwrite yes
auto-aof-rewrit-percentage 100
auto-aof-rewrite-min-size 64mb

快照持久化和AOF持久化的對比和選擇

對比

命令	快照持久化	AOF持久化
啓動優先級	低	高
體積	小	大
恢復速度	快	慢
數據安全性	丟數據	根據策略決定
輕重	重	輕

選擇

在實際生產環境中，根據數據量、應用對數據的安全要求、預算限制等不一樣狀況，會有各類各樣的持久化策略；如徹底不使用任何持久化、使用快照持久化或AOF持久化的一種，或同時開啓快照持久化和AOF持久化等。此外，持久化的選擇必須與Redis的主從策略一塊兒考慮，由於主從複製與持久化一樣具備數據備份的功能，並且主機master和從機slave能夠獨立的選擇持久化方案。

（1）若是Redis中的數據徹底丟棄也沒有關係（如Redis徹底用做DB層數據的cache），那麼不管是單機，仍是主從架構，均可以不進行任何持久化。

（2）在單機環境下（對於我的開發者，這種狀況可能比較常見），若是能夠接受十幾分鍾或更多的數據丟失，選擇快照持久化對Redis的性能更加有利；若是隻能接受秒級別的數據丟失，應該選擇AOF。

（3）但在多數狀況下，咱們都會配置主從環境，slave的存在既能夠實現數據的熱備，也能夠進行讀寫分離分擔Redis讀請求，以及在master宕掉後繼續提供服務。在這種狀況下，一種可行的作法是：master：徹底關閉持久化，這樣可讓master的性能達到最好slave：關閉快照持久化，開啓AOF（若是對數據安全要求不高，開啓快照持久化關閉AOF也能夠），並定時對持久化文件進行備份（如備份到其餘文件夾，並標記好備份的時間）；而後關閉AOF的自動重寫，而後添加定時任務，在天天Redis閒時（如凌晨12點）調用bgrewriteaof。

參考

[1] Josiah L.Carlson. Redis實戰[M]. 陳健宏譯. 北京：人民郵電出版社，2015.

[2]  Redis持久化方案該如何選型

[3]  一站式學習Redis-從入門到高可用分佈式實踐