Redis 配置數據持久化

1、Redis提供了哪些持久化機制

    1). RDB持久化：
    該機制是指在指定的時間間隔內將內存中的數據集快照寫入磁盤。    
    2). AOF持久化:
    該機制將以日誌的形式記錄服務器所處理的每個寫操做，在Redis服務器啓動之初會讀取該文件來從新構建數據庫，以保證啓動後數據庫中的數據是完整的。
    3). 無持久化：
    咱們能夠經過配置的方式禁用Redis服務器的持久化功能，這樣咱們就能夠將Redis視爲一個功能增強版的memcached了。
    4). 同時應用AOF和RDB。

    5). 若是要開啓AOF模式，修改Redis的配置文件redis.conf。

# 相關配置


appendonly yes  #開啓AOF模式 原文1
appendfilename "appendonly.aof" #保存數據的AOF文件名稱 原文1

# appendfsync always
appendfsync everysec    #fsync模式    原文2
# appendfsync no

no-appendfsync-on-rewrite no    #原文3

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb  #原文4

aof-load-truncated yes  #原文5

        官方文檔解釋以下： 

原文1：

By default Redis asynchronously dumps the dataset on disk. This mode is good enough in many applications, but an issue with the Redis process or a power outage may result into a few minutes of writes lost (depending on the configured save points).

The Append Only File is an alternative persistence mode that provides much better durability. For instance using the default data fsync policy (see later in the config file) Redis can lose just one second of writes in a dramatic event like a server power outage, or a single write if something wrong with the Redis process itself happens, but the operating system is still running correctly.

AOF and RDB persistence can be enabled at the same time without problems. If the AOF is enabled on startup Redis will load the AOF, that is the file with the better durability guarantees.

譯文1： 
Redis默認採用異步的方式將數據存放到磁盤上，這個模式對大部份應用來講是足夠好的，可是在Redis進程或電源發生故障的狀況下，可能會形成小部份的數據丟失，這取決於配置的保存時間點。 
Appendonly是一種可以提供很是好的持久化的模式，例如使用默認的Fsync方案，Redis能在發生服務器電源故障或操做系統仍然正常運行但Redis進程莫名掛掉的狀況下，只丟失1秒的數據。 
AOF與RDB模式能夠同時啓用，這並不衝突。若是AOF是可用的，那Redis啓動時將自動加載AOF，這個文件可以提供更好的持久性保障。

原文2：

The fsync() call tells the Operating System to actually write data on disk instead of waiting for more data in the output buffer. Some OS will really flush data on disk, some other OS will just try to do it ASAP.

Redis supports three different modes:

no: don’t fsync, just let the OS flush the data when it wants. Faster. 
always: fsync after every write to the append only log. Slow, Safest. 
everysec: fsync only one time every second. Compromise.

The default is 「everysec」, as that’s usually the right compromise between speed and data safety. It’s up to you to understand if you can relax this to 「no」 that will let the operating system flush the output buffer when it wants, for better performances (but if you can live with the idea of some data loss consider the default persistence mode that’s snapshotting), or on the contrary, use 「always」 that’s very slow but a bit safer than everysec.

If unsure, use 「everysec」.

譯文2： 
fsync()調用告訴操做系統將數據真實的寫入磁盤而不是放到緩衝區中，一些操做系統會真實的執行請求，還有一些操做系統只會盡力的嘗試。

Redis支持3種不一樣的模式： 
no：不即時同步，由操做系統控制什麼時候刷寫到磁盤上，這種模式速度最快； 
always：每次只寫日誌，速度較慢，但最安全； 
everysec：每秒鐘同步一次，折中的方案。

默認的模式是「everysec」，它一般是在速度和數據安全之間折中的方法。若是你能夠控制操做系統在Redis須要的時候去刷寫緩衝區那可使用「no」模式，可以提供更好的性能（但若是你能接受一些數據丟失，能夠考慮默認的持久化模式–快照方式），相反，使用「always」模式很慢，可是它比「everysec」模式要安全一點。

若是不肯定，就使用「everysec」。

原文3：

When the AOF fsync policy is set to always or everysec, and a background saving process (a background save or AOF log background rewriting) is performing a lot of I/O against the disk, in some Linux configurations Redis may block too long on the fsync() call. Note that there is no fix for this currently, as even performing fsync in a different thread will block our synchronous write(2) call.

In order to mitigate this problem it’s possible to use the following option that will prevent fsync() from being called in the main process while a BGSAVE or BGREWRITEAOF is in progress.

This means that while another child is saving, the durability of Redis is the same as 「appendfsync none」. In practical terms, this means that it is possible to lose up to 30 seconds of log in the worst scenario (with the default Linux settings).

If you have latency problems turn this to 「yes」. Otherwise leave it as 「no」 that is the safest pick from the point of view of durability.

譯文3： 
當使用AOF的fsync方案設置爲「always」或「everysec」時，後臺的存儲進程會執行大量的磁盤I/O操做，在一些Linux架構中，Redis在fsync()調用時可能會阻塞好久。這個問題當前並無修復，即便是在一個不一樣的線程執行fsync也將會阻塞咱們的同步寫調用。

爲了緩解這個問題，可使用如下選項，它將會在有一個BGSAVE或BGREWRITEAOF正在運行時，阻止主進程調用fsync()。

這意味着有另外一個子進程在存儲時，Redis的持久性等同於「appendfsync none」。在實踐中，意味着在最壞的狀況下它可能丟失多達30秒的日誌（默認的Linux設置）。

若是你有潛在的問題須要更改它爲「yes」。不然從持久性的觀點來看「no」是最安全的選擇。

原文4：

Automatic rewrite of the append only file. 
Redis is able to automatically rewrite the log file implicitly calling BGREWRITEAOF when the AOF log size grows by the specified percentage.

This is how it works: Redis remembers the size of the AOF file after the latest rewrite (if no rewrite has happened since the restart, the size of the AOF at startup is used).

This base size is compared to the current size. If the current size is bigger than the specified percentage, the rewrite is triggered. Also you need to specify a minimal size for the AOF file to be rewritten, this is useful to avoid rewriting the AOF file even if the percentage increase is reached but it is still pretty small.

Specify a percentage of zero in order to disable the automatic AOF rewrite feature.

譯文4： 
自動重寫append only文件。 
當AOF日誌的大小根據指定的百分比增加時，Redis會暗中調用BGREWRITEAOF去自動重寫日誌文件。

工做原理：Redis記憶AOF文件最後一次重寫的大小（若是重啓後沒有重寫發生，AOF的大小在啓動時會被使用）。

基本大小對比當前大小。若是當前大小比指定的百分比大，觸發重寫。而且你要爲AOF文件指定一個最小的尺寸去重寫，這對於避免重寫AOF文件是有用的，即便達到了百分比增加率但它仍然是很是小的。

指定百分比爲0以便禁用自動AOF重寫。

原文5：

An AOF file may be found to be truncated at the end during the Redis startup process, when the AOF data gets loaded back into memory. 
This may happen when the system where Redis is running crashes, especially when an ext4 filesystem is mounted without the data=ordered option (however this can’t happen when Redis itself crashes or aborts but the operating system still works correctly).

Redis can either exit with an error when this happens, or load as much data as possible (the default now) and start if the AOF file is found to be truncated at the end. The following option controls this behavior.

If aof-load-truncated is set to yes, a truncated AOF file is loaded and the Redis server starts emitting a log to inform the user of the event. Otherwise if the option is set to no, the server aborts with an error and refuses to start. When the option is set to no, the user requires to fix the AOF file using the 「redis-check-aof」 utility before to restart the server.

Note that if the AOF file will be found to be corrupted in the middle the server will still exit with an error. This option only applies when Redis will try to read more data from the AOF file but not enough bytes will be found.

譯文5： 
可能發現一個AOF文件在Redis啓動過程當中被截斷，當AOF數據被加載回內存時。 
這可能發生在系統中Redis運行崩潰，尤爲是掛載一個EXT4文件系統而沒有使用「data=ordered」選項時（可是這不會發生在Redis自身崩潰或中斷而操做系統仍然正常運行的時候）。

當有一個錯誤發生時Redis要麼退出，要麼加載儘量多的數據（當前默認）啓動，若是AOF文件最後發現被截斷。如下選項控制這個行爲。

若是aof-load-truncated被設置爲「yes」，一個被截斷的AOF文件將會被加載，Redis服務啓動發出一個日誌告知用戶這個事件。若是這個選項設置爲「no」，服務器停止一個錯誤並拒絕啓動。當選項被設置爲「no」，用戶須要在重啓服務以前使用「redis-check-aof」功能肯定AOF文件。

須要注意的是若是AOF文件被發現是損壞的，那服務器仍然會以一個錯誤退出。這個選項僅適用於Redis但願讀取更多的數據可是沒有發現足夠的字節時。

 

2、RDB機制的優點和劣勢

   RDB存在哪些優點呢？

    1). 一旦採用該方式，那麼你的整個Redis數據庫將只包含一個文件，這對於文件備份而言是很是完美的。好比，你可能打算每一個小時歸檔一次最近24小時的數據，同時還要天天歸檔一次最近30天的數據。經過這樣的備份策略，一旦系統出現災難性故障，咱們能夠很是容易的進行恢復。
    2). 對於災難恢復而言，RDB是很是不錯的選擇。由於咱們能夠很是輕鬆的將一個單獨的文件壓縮後再轉移到其它存儲介質上。
    3). 性能最大化。對於Redis的服務進程而言，在開始持久化時，它惟一須要作的只是fork出子進程，以後再由子進程完成這些持久化的工做，這樣就能夠極大的避免服務進程執行IO操做了。
    4). 相比於AOF機制，若是數據集很大，RDB的啓動效率會更高。
   
   RDB又存在哪些劣勢呢？

    1). 若是你想保證數據的高可用性，即最大限度的避免數據丟失，那麼RDB將不是一個很好的選擇。由於系統一旦在定時持久化以前出現宕機現象，此前沒有來得及寫入磁盤的數據都將丟失。
    2). 因爲RDB是經過fork子進程來協助完成數據持久化工做的，所以，若是當數據集較大時，可能會致使整個服務器中止服務幾百毫秒，甚至是1秒鐘。

   
3、AOF機制的優點和劣勢

   AOF的優點有哪些呢？

    1). 該機制能夠帶來更高的數據安全性，即數據持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不一樣步。事實上，每秒同步也是異步完成的，其效率也是很是高的，所差的是一旦系統出現宕機現象，那麼這一秒鐘以內修改的數據將會丟失。而每修改同步，咱們能夠將其視爲同步持久化，即每次發生的數據變化都會被當即記錄到磁盤中。能夠預見，這種方式在效率上是最低的。至於無同步，無需多言，我想你們都能正確的理解它。
    2). 因爲該機制對日誌文件的寫入操做採用的是append模式，所以在寫入過程當中即便出現宕機現象，也不會破壞日誌文件中已經存在的內容。然而若是咱們本次操做只是寫入了一半數據就出現了系統崩潰問題，不用擔憂，在Redis下一次啓動以前，咱們能夠經過redis-check-aof工具來幫助咱們解決數據一致性的問題。
    3). 若是日誌過大，Redis能夠自動啓用rewrite機制。即Redis以append模式不斷的將修改數據寫入到老的磁盤文件中，同時Redis還會建立一個新的文件用於記錄此期間有哪些修改命令被執行。所以在進行rewrite切換時能夠更好的保證數據安全性。
    4). AOF包含一個格式清晰、易於理解的日誌文件用於記錄全部的修改操做。事實上，咱們也能夠經過該文件完成數據的重建。
   
    AOF的劣勢有哪些呢？
    1). 對於相同數量的數據集而言，AOF文件一般要大於RDB文件。
    2). 根據同步策略的不一樣，AOF在運行效率上每每會慢於RDB。總之，每秒同步策略的效率是比較高的，同步禁用策略的效率和RDB同樣高效。

4、具體配置實現方式介紹

   1. Snapshotting:

    缺省狀況下，Redis會將數據集的快照dump到dump.rdb文件中。此外，咱們也能夠經過配置文件來修改Redis服務器dump快照的頻率，在打開6379.conf文件以後，咱們搜索save，能夠看到下面的配置信息：
    save 900 1              #在900秒(15分鐘)以後，若是至少有1個key發生變化，則dump內存快照。
    save 300 10            #在300秒(5分鐘)以後，若是至少有10個key發生變化，則dump內存快照。
    save 60 10000        #在60秒(1分鐘)以後，若是至少有10000個key發生變化，則dump內存快照。
    
   2. Dump快照的機制：

    1). Redis先fork子進程。
    2). 子進程將快照數據寫入到臨時RDB文件中。
    3). 當子進程完成數據寫入操做後，再用臨時文件替換老的文件。
    
   3. AOF文件：

    上面已經屢次講過，RDB的快照定時dump機制沒法保證很好的數據持久性。若是咱們的應用確實很是關注此點，咱們能夠考慮使用Redis中的AOF機制。對於Redis服務器而言，其缺省的機制是RDB，若是須要使用AOF，則須要修改配置文件中的如下條目：
    將appendonly no改成appendonly yes
    從如今起，Redis在每一次接收到數據修改的命令以後，都會將其追加到AOF文件中。在Redis下一次從新啓動時，須要加載AOF文件中的信息來構建最新的數據到內存中。
    
   4. AOF的配置：

    在Redis的配置文件中存在三種同步方式，它們分別是：
    appendfsync always     #每次有數據修改發生時都會寫入AOF文件。
    appendfsync everysec  #每秒鐘同步一次，該策略爲AOF的缺省策略。
    appendfsync no          #從不一樣步。高效可是數據不會被持久化。
    
   5. 如何修復壞損的AOF文件：

    1). 將現有已經壞損的AOF文件額外拷貝出來一份。
    2). 執行"redis-check-aof --fix <filename>"命令來修復壞損的AOF文件。
    3). 用修復後的AOF文件從新啓動Redis服務器。
    
   6. Redis的數據備份：

    在Redis中咱們能夠經過copy的方式在線備份正在運行的Redis數據文件。這是由於RDB文件一旦被生成以後就不會再被修改。Redis每次都是將最新的數據dump到一個臨時文件中，以後在利用rename函數原子性的將臨時文件更名爲原有的數據文件名。所以咱們能夠說，在任意時刻copy數據文件都是安全的和一致的。鑑於此，咱們就能夠經過建立cron job的方式定時備份Redis的數據文件，並將備份文件copy到安全的磁盤介質中。 

 

5、內存型數據庫Redis持久化小結

 

        Redis能夠經過建立快照來得到在內存裏面的數據在某一個時間點上的副本。在建立快照以後，用戶能夠對快照進行備份，能夠將快照複製到其它服務器從而建立具備相同數據的服務器副本，還能夠將快照留在原地以便重啓服務器時使用。

        有兩個命令能夠用於生成RDB文件，一個是SAVE，另一個BGSAVE。

        在只使用快照持久化來保存數據時，若是系統真的發生崩潰，用戶將丟失最近一次生成快照以後更改的全部數據。所以，快照持久化只適用於那些即便丟失一部分數據也不會形成問題的應用程序。

SAVE

        特色：SAVE命令會阻塞Redis服務器進程，直到RDB文件建立完畢，在服務器進程阻塞期間，服務器不能處理任何命令請求。

        缺點：服務器持久化期間沒法接受其它請求。

BGSAVE

        特色：BGSAVE命令則會派生出一個子進程，而後由子進程負責建立RDB文件，服務器進程則繼續處理命令請求。

        缺點：建立子進程所耗費的時間會隨着Redis佔用的內存而增長。

AOF持久化

    AOF持久化會將被執行的寫命令寫到AOF文件的末尾，以此來紀錄數據所發生的變化，所以，Redis只要從頭至尾從新執行一次AOF文件所包含的全部寫命令，就能夠恢復AOF文件所記錄的數據集。

    在設置同步頻率的時候，存在三個選項：

 

選項	同步頻率
always	每一個Redis寫命令都要同步寫入硬盤，可是這樣作會佔用Redis所擁有的內存，嚴重下降Redis的速度
everysec	每秒執行一次同步，顯式地將多個寫命令同步到硬盤
no	讓操做系統來決定應該什麼時候進行同步

 

        最好使用everysec，既能避免每次都寫入所形成的性能影響，又能避免操做系統崩潰所致使的可能丟失不定量數據，其即便系統崩潰，用戶最多隻會丟失一秒以內產生的數據，當硬盤忙於執行寫入操做的時候，Redis還會優雅的放慢本身的速度以便適應硬盤的最大寫入速度。

        缺點：由於Redis會不斷的將被執行的寫命令紀錄到AOF文件裏面，因此隨着Redis不斷執行，AOF文件的體積也會不斷增加，極端條件下，AOF甚至可能會用完硬盤的全部可用空間。

        爲了解決上面的缺點，Redis提供了BGREWRITEAOF命令，這個命令會經過移除AOF文件中的冗餘命令來重寫AOF文件，使得AOF文件儘量的小。它的原理和BGSAVE命令類似，Redis會建立一個子進程，而後由子進程負責對AOF文件進行重寫，由於AOF文件重寫也須要用到子進程，因此一樣存在快照持久化由於建立子進程所致使的性能問題和內存佔用問題。