redis 持久化 RDB和AOF的選擇

1. RDB持久化方式能夠在指定的時間間隔能對你的數據進行快照存儲
   
   AOF持久化方式記錄每次對服務器寫的操作,當服務器重啓的時候會重新執行這些
   命令來恢復原始的數據,AOF命令以redis協議追加保存每次寫的操作到文件末尾.
   Redis還能對AOF文件進行後臺重寫,使得AOF文件的體積不至於過大
    
2. 只做緩存：如果你只希望你的數據在服務器運行的時候存在,你也可以不使用任何持久化方式.
    
3. 同時開啓兩種持久化方式
   
   在這種情況下,當redis重啓的時候會優先載入AOF文件來恢復原始的數據,
   因爲在通常情況下AOF文件保存的數據集要比RDB文件保存的數據集要完整.
   
   RDB的數據不實時，同時使用兩者時服務器重啓也只會找AOF文件。那要不要只使用AOF呢？
   作者建議不要，因爲RDB更適合用於備份數據庫(AOF在不斷變化不好備份)，
   快速重啓，而且不會有AOF可能潛在的bug，留着作爲一個萬一的手段。
    
4. 性能建議：
    

   因爲RDB文件只用作後備用途，建議只在Slave上持久化RDB文件，而且只要15分鐘備份一次就夠了，只保留save 900 1這條規則。

   
   如果Enalbe AOF，好處是在最惡劣情況下也只會丟失不超過兩秒數據，啓動腳本較簡單隻load自己的AOF文件就可以了。代價一是帶來了持續的IO，二是AOF rewrite的最後將rewrite過程中產生的新數據寫到新文件造成的阻塞幾乎是不可避免的。只要硬盤許可，應該儘量減少AOF rewrite的頻率，AOF重寫的基礎大小默認值64M太小了，可以設到5G以上。默認超過原大小100%大小時重寫可以改到適當的數值。

   
   如果不Enable AOF ，僅靠Master-Slave Replication 實現高可用性也可以。能省掉一大筆IO也減少了rewrite時帶來的系統波動。代價是如果Master/Slave同時倒掉，會丟失十幾分鐘的數據，啓動腳本也要比較兩個Master/Slave中的RDB文件，載入較新的那個。新浪微博就選用了這種架構