2017-01-01 16:42:13 該系列文章鏈接NoSQL 資料庫簡介Redis的安裝及及一些雜項基礎知識Redis 的常用五大數據類型（key,string,hash,list,set,zset）Redis 配置文件介紹 Redis 持久化之RDB Redis 持久化之AOFRedis 主從 ...
2017-01-01 16:42:13
該系列文章鏈接
NoSQL 資料庫簡介
Redis的安裝及及一些雜項基礎知識
Redis 的常用五大數據類型（key,string,hash,list,set,zset）
Redis 配置文件介紹
Redis 持久化之RDB
Redis 持久化之AOF
Redis 主從複製
Redis 事務
Redis 發佈與訂閱
Redis jdedis 介紹
Redis 官網介紹 持久化（RDB 與 AOF）
1.AOF: Append only file
AOF 以日誌的形式記錄每個寫操作，將 Redis 執行過的所有寫指令記錄下來，不記錄讀操作。
只需追加文件但不可以改寫文件，redis 啟動之初會讀取該文件重新構建數據，也就是說，redis 重啟的話就根據日誌文件的內容將寫指令從前到後執行一次已完成數據的恢復工作
aof 保存的文件是 appendonly.aof 文件
2.AOF 在 redis.conf 的一些配置
2.1 appendonly
預設情況下，Redis非同步轉儲數據集到磁碟上。此模式在許多應用程式中都足夠好，但例如如果Redis進程會由於停電的問題而導致幾分鐘的寫入丟失（取決於配置的保存點）。
AOF 是一種備用持久化模式，可提供更好的持久化。例如，使用預設數據 fsync 策略（請參閱配置文件中的後面部分）Redis在伺服器斷電等戲劇性事件中只會丟失一秒寫入，如果Redis進程本身出現問題，則會丟失一次，但是操作系統仍然正常運行。
可以同時啟用AOF和RDB持久化以保證不會出現問題。
如果在啟動時啟用AOF，Redis將載入AOF，即文件
將具有更好的持久性保證。
請查看 http://redis.io/topics/persistence 以獲取更多信息。
總的來說，這個配置是 開啟或關閉AOF 的總配置
2.2 appendfilename
AOF 文件的名稱（預設："appendonly.aof"）
2.3 appendfsync
調用 fsync（）將讓操作系統實際寫入數據到磁碟上，而不是等待輸出緩衝區中的更多數據。某些操作系統會真正刷新數據到磁碟上，其他一些操作系統會儘快嘗試這樣做。
Redis支持三種不同的模式：
no：不要 fsync，只需讓操作系統在需要時刷新數據。速度更快。
always：每次有寫入操作都會調用 fsync,將寫入操作記錄到 appendonly.aof 中。慢，最安全。
everysec：每秒調用一次 fsync ，將寫入操作記錄到 appendonly.aof 中。妥協方案。
預設值為“everysec”，因為這通常是速度和數據安全之間的正確折衷。這取決於你是否可以理解不總是讓操作系統在需要時刷新輸出緩衝區，以獲得更好的性能（但如果你能想到一些數據丟失的想法，請考慮預設的持久化模式，也就是 RDB），或相反，使用“always”，將非常慢，但比 everysec 方案更安全。
更多詳情請查看以下文章：http：//antirez.com/post/redis-persistence-demystified.html
如果不確定，請使用“everysec”。
2.4 no-appendfsync-on-rewrite
當AOF fsync策略設置為always或everysec且後臺保存進程（後臺保存或AOF日誌後臺重寫）正在對磁碟執行大量I/O操作時，在某些Linux配置中，Redis可能會阻塞太長時間在 fsync（）調用。請註意，目前沒有對此進行修複，因為即使在不同的線程中執行 fsync 也會阻塞我們的同步 write(2) 的調用。
為了緩解這個問題，當BGSAVE或BGREWRITEAOF正在進行中時可以使用這個配置來阻止在主進程中調用fsync()。
這意味著當另一個子進程正在保存時，Redis的 appendfsync 策略將會與“appendfsync none”相同。實際上，這意味著在最糟糕的情況下（使用預設的Linux設置）可能會丟失最多30秒的日誌。
如果您有延遲問題，請將其轉為 "yes"。否則，從耐用性的角度來看，它是最“最安全”的選擇使用 "no"。
2.5 auto-aof-rewrite-percentage/auto-aof-rewrite-min-size
自動重寫 appendonly.file 。
當AOF日誌大小增長到指定的百分比(即 auto-aof-rewrite-percentage的值)時，Redis能夠自動重寫日誌文件，隱式調用 BGREWRITEAOF。
這是它的工作原理：Redis會在最近的重寫後記住AOF文件的大小（如果重啟後沒有重寫，則使用啟動時的AOF大小）。
將此基本大小與當前大小進行比較。如果當前大小大於指定的百分比，則觸發重寫。此外，您需要指定要重寫的AOF文件的最小大小，這有助於避免重寫AOF文件，即使達到 auto-aof-rewrite-percentage 但仍然非常小。
指定 auto-aof-rewrite-percentage = 0 以禁用自動AOF重寫功能。
2.6 aof-load-truncated
如果系統（尤其是在沒有data = ordered選項的情況下掛載ext4文件系統）出現崩潰且此時 Redis 啟動進程在使用 AOF 的 appendonly.aof 文件將數據載入回記憶體時，可能會發生 appendonly.aof 末尾出現錯誤（也就是末尾被截斷，文件不正常終止）這種情況（但是當Redis本身崩潰或中止但操作系統仍能正常工作時，這種情況不會發生）。
發生這種情況時，Redis可以退出，或者載入儘可能多的數據（預設值），如果發現AOF文件在末尾被截斷，則啟動。此選項控制此行為。
如果將aof-load-truncated設置為yes，則會載入截斷的AOF文件，並且Redis伺服器會開始發出日誌以通知用戶該事件。
否則，如果該選項設置為no，則伺服器將中止並顯示錯誤並拒絕啟動。當該選項設置為no時，用戶需要使用“redis-check-aof”實用程式修複AOF文件，然後才能重新啟動伺服器。
請註意，如果發現AOF文件在中間被破壞，伺服器仍將退出並顯示錯誤。此選項僅在Redis嘗試從AOF文件中讀取更多數據但不會找到足夠的位元組時適用。
2.7 aof-use-rdb-preamble
重寫AOF文件時，Redis能夠使用AOF文件中的RDB前導碼來加快重寫和恢復速度。啟用此選項後，重寫的AOF文件由兩個不同的節組成：
[RDB文件] [AOF尾]
載入時Redis識別出AOF文件以“REDIS”字元串開頭並載入首碼RDB文件，並繼續載入AOF尾部。
3.AOF rewrite
3.1 重寫
AOF 採用文件追加的方式，文件會越來越大為避免出現此種情況，新增重寫機制。
當 AOF 文件大小超過所設定的閾值時，Redis 就會啟動 AOF 文件的內容壓縮，只保留可以恢複數據的最小指令集。可以使用命令 bgrewriteaof
3.2 重寫原理
AOF 文件持續增長而過大時，會 fork 出一條新進程來講文件重寫（先寫臨時文件最後在改名,預設名字為 appendonly.aof)，遍歷新進程的記憶體中數據，每條記錄有一條 set 語句，重寫 aof 文件，並沒有讀取舊的 aof 文件
而是將整個記憶體中的數據用命令的方式重寫了一個新的 aof 文件，這點和快照有點類似
3.3 重寫觸發機制
Redis 會記錄賞賜重寫時的 AOF 大小，預設配置是當 AOF 文件大小是上次 rewrite 後大小的已被且文件大小大於 64M 時觸發
4. AOF 同步策略
4.1 always:每次發生寫入操作時都會被立即記錄到磁碟，性能較差但數據完整性比較好
4.2 everysec:非同步操作，每秒記錄，如果在一秒內宕機，那麼將丟失 一秒的數據
4.3 no:不同步
5.AOF 劣勢
5.1 相同數據集的數據而言 aof 文件要遠大於 rdb 文件，恢復速度慢於 rdb
5.2 aof 運行效率要慢於 rdb, everysec 同步策略效率較好，no 同步策略效率和 rdb 相同
6.關於 RDB 和 AOF 這兩種持久化方式的總結
6.1 RDB
RDB 持久化方式能夠在指定的時間間隔內對你的數據進行快照存儲
6.2 AOF
AOF 持久化方式記錄每次對伺服器寫的操作，當伺服器沖i的時候會重新執行這些命令來恢複原始的數據。AOF 命令以 redis 協議追加保存每次寫的操作到文件末尾
redis 還能對 AOF 文件進行後臺重寫，使得 AOF 文件體積不至於過大
6.3 不開啟持久化
當然如果 redis 只做緩存的話，那麼可以不用任何持久化的方式
6.4 開啟持久化
但是如果不只做緩存，那麼最好同時開啟兩種持久化方式
在這種情況下，redis 重啟時會優先載入 AOF 文件來恢複原始的數據，因為在通常情況下 AOF 文件保存的數據要比 RDB 文件保存的數據要完整
那麼 RDB 數據不實時，而且同時使用兩者時伺服器重啟也只會找 AOF 文件，要不要只使用 AOF 呢？（我有一個大膽的想法，你要不要聽聽）
redis 開發人員建議不要，因為 RDB 更適合用於備份資料庫，AOF 在不斷變化不好備份
而且快速重啟後，RDB 不會有 AOF 可能潛在的bug,留著 RDB 可以作為一個以防萬一的手段
6.4 開啟了主從複製且開啟了持久化
因為RDB文件只用作後備用途，建議只在Slave上持久化RDB文件，而且只要15分鐘備份一次就夠了，即只保留save 900 1這條規則。
如果開啟 AOF，好處是在最惡劣情況下也只會丟失不超過30秒數據，啟動腳本較簡單隻載入自己的AOF文件就可以了。代價一是帶來了持續的IO，二是AOF 重寫的最後將重寫過程中產生的新數據寫到新文件造成的阻塞幾乎是不可避免的。只要硬碟許可，應該儘量減少AOF 重寫的頻率，AOF重寫的基礎大小預設值64M太小了，可以設到5G以上。預設超過原大小100%大小時重寫可以改到適當的數值，例如80%。
如果不開啟 AOF ，僅靠主從複製實現高可用性也可以。能省掉一大筆IO也減少了重寫時帶來的系統波動。代價是如果Master/Slave同時倒掉，會丟失十幾分鐘的數據，啟動腳本也要比較兩個Master/Slave中的RDB文件以便載入較新的文件。
