redis(三) 持久化機制
以後會每天更新 更新內容大多是分散式部落格。
感覺不錯的加我java群 群號是：369784068
1.redis持久化機制
1.1 rdb持久化
在指定的時間間隔內將記憶體中的資料集快照寫入磁碟
redis.conf檔案中如下配置是rdb持久化
save 900 1
save 300 10
save 60 10000 rdb 儲存的dump.rdb檔案
rdb優勢：只包含一個檔案
災難恢復是好的選擇（單獨的檔案拷貝到別的儲存)
只fork出子程序，子程序完成持久化避免服務程序執行IO，能夠達到效能最大化
與aof相比，資料集大，啟動效率高。
rdb劣勢:
資料可能丟失
資料集較大,fork子程序可能會導致伺服器停止幾百毫秒，甚至1秒
1.2 aof持久化
以日誌的形式來記錄每個寫操作，redis啟動之初會讀取該檔案重新構建資料
保證資料的完整性
redis.conf檔案中
appendonly yes (預設是no改成yes就打開了aof持久化）
appendonly.aof檔案
aof優勢:
3種同步策略 每秒同步、每修改同步、不同步
appendfsync always 同步持久化 每次發生資料變更會被立即記錄到磁碟 效能較差
# appendfsync everysec 非同步操作，每秒記錄 如果一秒內宕機，有資料丟失
# appendfsync no 從不同步
帶來更高的資料安全
對日誌檔案的操作是append模式的，寫入過程中即使宕機，也不會破壞日誌檔案
已經存在的內容，如果寫一半出現宕機，redis在下次啟動之前，做一個redis-check-aof工作即可，使得資料一致
rewrite機制。
aof日誌檔案清晰、易懂
aof劣勢:相同資料集的資料而言aof檔案要遠大於rdb檔案
aof執行效率要慢於rdb,每秒同步策略效率較好，不同步效率和rdb相同
1.3 無持久化
1.4 同時使用rdb和aof方式
如果只打開rdb,啟動時通過rdb重建資料
如果只打開aof,啟動時通過aof重建資料
如果既打開了rdb又打開了aof,通過aof重建資料
redis-cli -a pwd bgsave
redis-cli -a pwd bgrewriteaof
通過命令顯示啟動rdb記錄 aof記錄
2.redis 複製流程
2.1 slaveof指令可以配置方式也可以是命令方式，slave端有定時器觸發事件連線master,
傳送sync命令,阻塞等待master傳送其記憶體快照（新版不用阻塞)
2.2master端收到sync命令,判斷是否有子程序做記憶體快照，有等待其完成，沒有立即
開始記憶體快照，快照完成後，將該檔案傳送給slave端
2.3slave接收到記憶體快照，儲存到本地.接收完，清空記憶體，重新讀取發來的
記憶體快照，重新建立整個記憶體資料
2.4此時master如果有修改更新，暫時先發送到快取佇列，等slave快照完成後，依次
再發給slave.
3.複製缺陷
無增量複製概念，每次重新連線都要取master全部記憶體快照，並清空資料，重新記憶體資料
redis叢集需要主從複製，最好事先配置好所有的從庫，避免中途再去增加從庫
redis持久化機制還不是特別成熟 Cache/Store
4.在實際應用中redis複製機制、影響效率
解決方案:自己完成增量同步的工作
首先寫redis 的aof檔案,並對這個檔案按檔案的大小進行自動分割回滾。
同時關閉redis的rewrite命令，然後會在業務低峰時間進行記憶體快照儲存，
並把當前的AOF檔案位置一起寫入到快照檔案中，這樣我們可以是快照檔案
和aof檔案的位置保持一致性。這樣我們就得到了系統某一時刻的記憶體快照，
並且同時你也知道了這一時刻對應的AOF檔案的位置，當從庫傳送同步命令
的時候，首先會把快照檔案傳送給從庫，然後從庫會去取出快照檔案儲存
的AOF檔案位置，並將該位置發給主庫，主庫隨後傳送該位置之後的所有命令，
以後的複製就都是這個位置之後的增量資訊了。
也有一些中介軟體，專門來解決這個問題。Twitter專門開發了一個用於複製
和分割槽的中介軟體gizzard(主動複製避開redis複製缺陷)