redis的RDB快照和AOF日志

RDB的問題
　　1：fork
　　　　一個進程時，內存的數據也被復制了，即內存會是原來的兩倍
　　2：每次快照持久化都是將內存數據完整寫入到磁盤一次，並不是增量的只同步臟數據。
　　　　如果數據量大的話，而且寫操作比較多，必然會引起大量的磁盤io操作，可能會嚴重影響性能。
　　3：由於快照方式是在一定間隔時間做一次的，所以如果redis意外down掉的話，就會丟失最后一次快照后的所有修改。
觸發快照的情況
　　1：根據配置規則進行自動快照
　　2：用戶執行save或bgsave命令
　　3：執行flushall命令
　　4：執行復制replication時
  　　  save命令執行
      　　  Save命令時，Redis會阻塞所有客戶端的請求，然后同步進行快照操作。
    　　bgsave命令
       　　 執行bgsave命令時，Redis會在后台異步進行快照操作，快照同時還可以響應客戶端請求。可以通過lastsave命令獲取最后一次成功執行快照的時間。
    　　flushall命令
      　　  這個命令會導致redis清除內存中的所有數據，如果定義了自動快照的條件，那么無論是否滿足條件，都會進行一次快照操作；如果沒有定義自動快照的條件，那么就不執　　　 行快照
AOF的問題
      默認的AOF持久化策略是每秒鍾fsync一次，fsync是指把緩存中的寫指令記錄到磁盤中，
在這種情況下，redis扔可以保持很高的性能
     當然由於OS會在內核中緩存write做的修改，所以可能不是立即寫到磁盤上。
這樣aof方式的持久化也還是有可能會丟失部分修改。不過可以通過配置文件告訴redis，想要通過fsync函數強制os寫入磁盤的時機
     AOF方式在同等數據規模的情況下，AOF文件要比RDB文件的體積大，因此AOF方式的恢復速度也要慢於RDB方式
AOF日志恢復
     如果在追加日志時，恰好遇到磁盤空間滿或斷電等情況，導致日志寫入不完整，也沒有關系，
redis提供了redis-check-aof工具，可以用來進行日志修復，基本步驟如下：
    1、備份被寫壞的AOF文件
    2、運行redis-check-aof -fix進行修復
    3、用diff -u來看下兩個文件的差異，確認問題點
    4、重啟redis，加載修復后的AOF文件
AOF重寫
    AOF采用文件追加方式，這樣會導致AOF文件越來越大，為此，redis提供了AOF文件重寫（rewrite）機制，即當AOF文件的大小超過所
設定的閾（yu）值時，redis就會啟動AOF文件的內容壓縮，只保留可以恢復數據的最小指令集。可以使用命令bgrewriteaof.