持久化之AOF（Append Only File）

預設是不開啟的 我們只需要將appendonly改為yes就開啟了aof！
以日誌的形式來記錄每個寫操作，將Reids執行過的寫入指令記錄下來，只許追加檔案但不可以改寫檔案，redis啟動之初會讀取aof檔案重新構建資料，換言之，redis重啟的話就根據日誌檔案的內容將寫指令全部執行一次以完成資料的恢復工作。

如果aof檔案被噁心修改、損壞，redisg是不能啟動的，此時可以使用redis-check-aof來進行修復

1 redis-check-aof --fix

但是修復後，可能會丟失一些資料

重寫規則

若aof檔案大於指定值，會fork一個新子程序將檔案重寫

優點

• 每一次修改都同步，確保檔案的完整性
• 每秒同步一次，可能會丟失一秒的資料
• 從不同步，效率最高

缺點

• 相對於資料檔案來說，aof遠遠大於rdb，修復速度比rdb慢
• aof執行效率要比rdb慢（涉及到大量的IO操作）

擴充套件

• 1、RDB持久化方式能夠在指定的時間間隔內對你的資料進行快照儲存

  2、AOF持久化方式記錄每次對伺服器寫的操作，當伺服器重啟的時候會重新執行這些命令來恢復原始的資料，AOF命令以Redis協議追加儲存每次寫的操作到檔案末尾，Redis還能對AOF檔案進行後臺重寫，使得AOF檔案的體積不至於過大。

  3、只做快取，如果你只希望你的資料在伺服器執行的時候存在，你也可以不適用任何持久化

  4、同時開啟兩種持久化方式

  • 在這種情況下，當redis重啟的時候會優先載入AOF檔案來恢復原始的資料，因為在通常情況下AOF檔案儲存的資料集要比RDB檔案儲存的資料集要完整。
  • RDB的資料不實時，同時使用兩者時伺服器重啟也只會找AOF檔案，那要不要只使用AOF呢？作者建議不要，因為RDB更適合用於備份資料庫（AOF在不斷變化不好備份），快速重啟，而且不會有AOF可能潛在的Bug，留著作為一個萬一的手段。

  5、效能建議

  • 因為RDB檔案只用作後備用途，建議只在Slave上持久化RDB檔案，而且只要15分鐘備份一次就夠了，只保留save 900 1 這條規則
  • 如果Enable AOF ，好處是在最惡劣的情況下也只會丟失不超過兩秒的資料，啟動指令碼較簡單隻load自己的AOF檔案就可以了，代價一是帶來了持續的IO，二是AOF rewrite的最後將rewrite過程中產生的新資料寫到新檔案造成的阻塞幾乎是不可避免的。只要硬碟許可，應該儘量減少AOF rewrite的頻率，AOF重寫的基礎大小預設值64M太小了，可以設到5G以上，預設超過原大小100%大小重寫可以改到適當的數值。
  • 如果不Enable AOF，僅靠Master-Slave Reollcation實現高可用性也可以，能省掉一大筆IO，也減少了rewrite時帶來的系統波動。代價是如果Master/Slave同時宕機，會丟失十幾分鐘的資料，啟動指令碼也要比較兩個Master/Slave中的RDb檔案，載入較新的哪個，微博就是這種架構。