正常 就會 100% 傳輸 關閉 操作系統 響應 模式 日誌記錄

Redis持久化方式：

1、RDB    Redis DB
2、AOF    AppendOnlyFile 默認關閉

RDB方式：

默認情況下，Redis將數據庫快照保存在名字為dump.rdb的二進制文件中。
在RDB方式下，有兩種保存方式：
（1）、手動執行持久化數據命令來讓redis進行一次數據快照。
save：在客戶端手動執行save命令，它會阻塞Redis服務，無法響應客戶端請求，創建新的dump.rdb替代舊文件
bgsave：它是一個異步命令，非阻塞，Redis服務正常接收處理客戶請求，這種方式，Redis會fork（）一個新的子進程來創建RDB文件，子進程處理完後會向父進程發送一個信號，通知它處理完畢，然後父進程會用新的dump.rdb文件來替代舊文件

註意：Fork發生時，父進程內存共享，所以為了不影響子進程做數據快照，在這期間修改數據，將會被復制一份，而不進共享內存，所以說：RDB所持久化的數據，是Fork發生時的數據，在這樣的條件下進程持久化數據，如果因為某些情況宕機，則會丟失一部分數據，如果在實際生產中對數據丟失沒那麽敏感，丟失的也可以從傳統數據庫中獲取或者丟失部分也無所謂，那麽就可以選擇RDB持久化方式。
save和bgsave的比較：
<1>、save不用創建新的進程，速度略快，bgsave需要創建子進程，消費額外的內存
<2>、save適合停機維護，服務低谷時段，bgsave適合線上執行
（2）、另一種則是根據你所配置的配置文件中的策略，達到策略的某些條件時自動持久化數據，和bgsave執行原理相同

    save 900 1
    save 300 10
    save 60 10000

這是配置文件默認的策略，它們之間是或的關系，每個900秒，在這期間變化至少一個鍵值，做快照。或者每300秒，變化10個鍵值做快照。或者每60秒，變化10000個鍵值，做快照。

AOF方式：

append only file，采用追加的方式保存
默認文件是：appendonly.aof
它記錄所有的寫操作命令，在服務啟動的時候使用這些命令可以還原數據庫，調整AOF持久化策略，可以在服務出現故障時，不丟失任何數據，也能丟失一秒數據，相對於RDB來說損失小的多。
（1）、AOF寫入機制
事實上，AOF機制並不會立即將命令寫入到硬盤文件中，而是寫入到磁盤緩存，在接下來的策略中，配置多長時間來將硬盤緩存寫入到硬盤文件，所以在一定條件下，還是會丟失數據，不過丟失很少一部分。所以AOF方式不能保證絕對不能丟失數據。

（2）、寫入磁盤策略
Redis默認使用ervrysec，就是說每秒持久化一次，而always則是每次操作都會立即寫入aof文件中，而no則是不主動進行同步操作，是默認30s一次。
Always：服務器每寫入一個命令，就調用一個fdatasync，將緩沖區裏面的命令寫入到硬盤。這中模式下，服務器出現故障，也不會丟失任何已經成功執行的命令數據。
Everysec：服務器每一秒調用一次fdatasync，將緩沖區裏面的命令寫入到硬盤。這種模式下，服務器出現故障，最多只丟失一秒鐘內的執行命令數據。
No：服務器不主動調用fdatasync，由操作系統決定何時將緩沖區裏面的命令寫入到硬盤。這種模式下，服務器遭遇意外故障時，丟失命令的數量是不確定的。
運行速度：always的速度慢，everysec和no都很快。
（3）AOF重寫機制：
AOF有序的記錄了redis的命令操作，意外情況下丟失數據很少，它不斷地對APF文件添加操作日誌記錄，redis有專門的優化策略來優化日誌記錄文件過大的問題。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

前者是指超過上一次aof重寫aof文件大小的百分之多少，會再次優化，如果沒有重寫，則以啟動時為主，後者是限制了允許重寫的最小aof文件大小，bgrewritesof命令是手動重寫命令，會fock子進程，在臨時文件中重寫數據庫狀態對原apf無任何影響，當重建舊的狀態後，也會把fock發生後的一段時間內的數據一並追加到臨時文件，最後替換原有的aof文件，新的命令繼續向新的aof文件中追加。
重寫的過程：
fock一個子進程負載重寫AOF文件
子進程會創建一個臨時文件寫入AOF信息
父進程會開辟一個內存緩沖區接收新的寫入命令
子進程重寫完成後，父進程會獲得一個信號，將父進程接收到的新的寫入操作由子進程寫入到臨時文件中
新文件替換舊文件
註：如果寫入操作的時候出現故障導致命令寫半截，可以使用redis-check-aof工具修復
AOF重寫觸發：
手動：客戶端向服務器發送BGREWRITEAOF命令
自動：配置文件中配置自動執行BGREWRITEAOF命令

auto-aof-rewrite-min-size <size>
觸發AOF重寫所需的最小體積：只要在AOF文件的體積大於等於size，才會考慮是否需要進行重寫AOF，這個選項用於避免對體積過小的AOF文件重寫
auto-aof-rewrite-percentage <percent>
指定觸發所需的AOF文件體積的百分比：當AOF文件的體積大於指定的體積，並且超過上一次重寫之後的AOF文件體積的percent%時，就會觸發AOF重寫。這個值設置為0表示關閉自動AOF重寫。

舉例：

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
appendonly no / yes

當AOF大於64M的時候，可以考慮AOF文件重寫
只有當AOF文件的增量大於起始值size的100%時，啟動重寫， 默認是關閉

RDB和AOF比較：

1、RDB
優點：
完全備份，不同時間的數據集備份可以做到多版本恢復
緊湊的單一文件，方便網絡傳輸，適合容災恢復
恢復大數據集速度比AOF快
缺點：
會丟失最近寫入，修改的未能持久化的數據
fock過程非常耗時，會造成毫秒級不能響應客戶端請求
2、AOF
優點：
寫入機制，默認是ervrysec每秒執行，性能好不阻塞服務，最多丟失一秒數據
重寫機制，優化AOF文件
如果誤操作，比如fulshall等，只要AOF未被重寫，停止服務，移除AOF文件尾部FUSHALL命令，重啟redis，可以將數據集恢復到flushall執行前的狀態
缺點：
相同數據集，AOF文件體積比RDB大很多
恢復數據庫速度比RDB慢

Redis持久化方式AOF和RDB