Redis配置數據持久化---APPEND ONLY MODE
Redis可以實現數據的持久化存儲，即將數據保存到磁盤上。
Redis的持久化存儲提供兩種方式：RDB與AOF。RDB是默認配置。AOF需要手動開啟。
現在Redis的配置中默認是關閉AOF模式的。
如果要開啟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希望讀取更多的數據但是沒有發現足夠的字節時。