Redis學習日記--redis持久化
1.什麼是持久化
將資料從掉電易失的記憶體存放到能夠永久儲存的裝置上
2.Redis持久化方式
RDB（Redis DB）
AOF（AppendOnlyF
Redis持久化-RDB
在預設情況下，Redis 將資料庫快照儲存在名字為 dump.rdb的二進位制檔案中
執行策略：
自動：按照配置檔案中的條件滿足就執行BGSAVE
手動：客戶端發起SAVE、BGSAVE命令
SAVE命令
1.redis > save
2.阻塞Redis服務，無法響應客戶端請求
3.建立新的dump.rdb替代舊檔案
BGSAVE命令
1.redis > bgsave
2.非阻塞，Redis服務正常接收處理客戶端請求
3.Redis會fork()一個新的子程序來建立RDB檔案，子程序處理完後會向父程序傳送一個訊號，通知它處理完畢
4.父程序用新的dump.rdb替代舊檔案
BGSAVE命令是一個非同步命令（shell的父子程序）。執行過程流圖如下：
1.fork()：copy on writ
2.子程序記憶體中儲存父程序記憶體的指向，不必開闢資料大小的記憶體佔用
3.父程序不會阻塞，如果客戶端修改了父程序的記憶體，阻塞（cow）：父程序的值，然後在子程序中開闢（舊的）。父程序才真正修改。：阻塞是很小。
4.9：00 BGSAVE 10：00完成，持久化資料儲存的是9：00
優點
完全備份，不同時間的資料集備份可以做到多版本恢復
緊湊的單一檔案，方便網路傳輸，適合災難恢復
恢復大資料集速度較AOF快
缺點
會丟失最近寫入、修改的而未能持久化的資料
fork過程非常耗時，會造成毫秒級不能響應客戶端請求
SAVE 和 BGSAVE 命令相對比
SAVE不用建立新的程序，速度略快
BGSAVE需要建立子程序，消耗額外的記憶體
SAVE適合停機維護，服務低谷時段
BGSAVE適合線上執行
Redis持久化-AOF
Append only file，採用追加的方式儲存;
預設檔案appendonly.aof;
記錄所有的寫操作命令，在服務啟動的時候使用這些命令就可以還原資料庫;
調整AOF持久化策略，可以在服務出現故障時，不丟失任何資料，也可以丟失一秒的資料。相對於RDB損失小得多
AOF寫入機制
AOF方式不能保證絕對不丟失資料
目前常見的作業系統中，執行系統呼叫write函式，將一些內容寫入到某個檔案裡面時，為了提高效率，系統通常不會直接將內容寫入硬盤裡面，而是先將內容放入一個記憶體緩衝區（buffer）裡面，等到緩衝區被填滿，或者使用者執行fsync呼叫和fdatasync呼叫時才將儲存在緩衝區裡的內容真正的寫入到硬盤裡，未寫入磁碟之前，資料可能會丟失
寫入磁碟的策略
appendfsync選項，這個選項的值可以是always、everysec或者no
Always：伺服器每寫入一個命令，就呼叫一次fdatasync，將緩衝區裡面的命令寫入到硬碟。這種模式下，伺服器出現故障，也不會丟失任何已經成功執行的命令資料
Everysec（預設）：伺服器每一秒重呼叫一次fdatasync，將緩衝區裡面的命令寫入到硬碟。這種模式下，伺服器出現故障，最多隻丟失一秒鐘內的執行的命令資料
No：伺服器不主動呼叫fdatasync，由作業系統決定何時將緩衝區裡面的命令寫入到硬碟。這種模式下，伺服器遭遇意外停機時，丟失命令的數量是不確定的
執行速度：always的速度慢，everysec和no都很快
AOF重寫機制
AOF檔案過大
合併重複的操作，AOF會使用盡可能少的命令來記錄
重寫過程
fork一個子程序負責重寫AOF檔案
子程序會建立一個臨時檔案寫入AOF資訊
父程序會開闢一個記憶體緩衝區接收新的寫命令
子程序重寫完成後，父程序會獲得一個訊號，將父程序接收到的新的寫操作由子程序寫入到臨時檔案中
新檔案替代舊檔案
注：如果寫入操作的時候出現故障導致命令寫半截，可以使用redis-check-aof工具修復
優點
寫入機制，預設fysnc每秒執行，效能很好不阻塞服務，最多丟失一秒的資料
重寫機制，優化AOF檔案
如果誤操作了（FLUSHALL等），只要AOF未被重寫，停止服務移除AOF檔案尾部FLUSHALL命令，重啟Redis，可以將資料集恢復到 FLUSHALL 執行之前的狀態
缺點
相同資料集，AOF檔案體積較RDB大了很多
恢復資料庫速度叫RDB慢（文字，命令重演）