RDB

　　RDB持久化是指在指定的時間間隔內將內存中的數據集快照寫入磁盤(默認是 dump.rdb)。

　　默認持久化機制，就是將內存中的數據以快照的方式寫入二進制文件dump.rbd中。

　　觸發快照的條件

　　　　1.自己配置快照規則

　　　　　　save <second> <exchanges>

　　　　　　second 秒內，key的修改數量大於exchanges時，執行快照

　　　　　　save的關系是或的關系，都滿足

　　　　　　默認文件名為 dump.rdb

　　　　　　默認路勁為配置文件下的當前路徑

　　　　　　獲取配置文件中的快照規則 config get save

　　　　　　添加新規則，服務器重啟後失效，config set save "second exchanges"

　　　　2.save或bgsave

　　　　　　save：執行內存的數據同步到磁盤的操作，這個操作會阻塞客戶端的請求。（不要輕易執行，數據量大，阻塞時間差）

　　　　　　bgsave：在後臺異步執行快照操作，這個操作不會阻塞客戶端的請求。

　　　　3.執行flushall

　　　　　　清除內存中的所有數據，只要快照規則不為空，那麽redis就會執行快照。

　　　　4.執行復制的時候（集群）

　　快照的實現原理

　　　　redis會使用fork函數復制一份當前進程的副本（子進程）

　　　　父進程繼續處理客戶端請求。

　　　　fork進程負責把內存的數據同步到磁盤的臨時文件，當子進程將快照寫入臨時文件完畢後，用臨時文件替換原來的快照文件，然後子進程退出。

　　　　缺點：由於子進程是復制父進程，兩個內存大小相同的redis進程在系統上運行，會造成內存使用率大幅增加。

　　使用rdb的優缺點

　　　　優點：

　　　　　　1.只包含一個dump.rdb文件，方便備份移動。

　　　　　　2.rdb回復大數據集的速度比aof快。

　　　　　　3.rdb可以最大化redis性能，因為是子進程去處理保存工作，父進程無需執行io操作。

　　　　缺點：

　　　　　　1.rbd的規則是單位時間內改變多少個鍵，才會觸發，而在為改變之前，一旦服務器故障，就會丟失幾分鐘的數據

　　　　　　2.當數據量大時,fork子進程會非常耗時，會造成服務器在某毫秒或長達一秒的時間停止處理客戶端。並且子進程和父進程兩個進程會消耗更多的內存。

AOF

　　redis會將每一個收到的寫命令都通過write函數追加到文件中(默認是 appendonly.aof)。

　　如何配置

　　　　appendonly 改為yes

　　　　appendfilename：保存的文件名

　　　　當修改了值後，可以看到生成了新的文件appendonly.aof

　　　　vim appendonly.aof文件，可以看到每條記錄都被寫入aof文件中

　　同步磁盤數據出現的問題

　　　　redis每次更新數據時，aof機制都會將命令寫入aof文件中。

　　　　但是實際上由於操作系統的緩存機制，數據並沒有實時寫到磁盤，而是先寫入磁盤的緩沖區，再通過硬盤緩存機制刷新保存到文件中。

　　　　這樣就可能回出現數據丟失。

　　配置同步策略

　　　　appendfsync always：每次收到命令就立刻強制寫入磁盤，最慢，但是完全持久化，不推薦使用

　　　　appendfsync everysec：每秒鐘強制寫入磁盤一次，在性能和持久化方面做了很好的折中，推薦

　　　　appendfsync no　　：完全依賴os，性能最好，持久化沒保障。

　　　　每一秒都將命令寫入文件中，aof文件越來越大，並且很多語句會出現多余，所以引入了重寫策略。

　　重寫策略（優化aof文件）

　　　　auto-aof-rewrite-percentage 100 ：當aof文件大小超過上一次aof文件大小的百分之多少會重寫。如果之前沒重寫過，以啟動時aof文件大小為準。

　　　　auto-aof-rewrite-min-size 64mb ：限制允許重寫最小aof文件大小，也就是文件大小小於64mb，不需要進行優化。

　　重寫的實現原理

　　　　1.redis調用fork函數，復制一個子線程

　　　　2.父進程繼續處理client請求，將請求追加到aof文件，同時收到的命令緩存起來，這樣保證子進程重寫失敗不會出問題。

　　　　3.子進程根據內存中的數據快照，往臨時文件中寫入重建數據庫狀態的命令

　　　　4.當子進程將快照的命令寫入臨時文件後，通知父進程，然後父進程把緩存的寫命令也寫入臨時文件

　　　　5.當父進程寫完後，將臨時文件替換老的aof文件，後續命令往新的aof文件中追加

　　aof文件的修復

　　　　1.先復制原有的aof cp appendonly.aof appendonly.aof.bak

　　　　 2.執行 redis-check-aof --fix appendonly.aof 完成修復

　　aof的優缺點

　　　　優點：　　

　　　　　　1.aof的同步策略，可以讓aof安全性變的非常高，並且使用每秒同步一次，redis依然可以保證很好的性能，就算發生故障，也最多只丟失一秒的數據。

　　　　　　2.aof采用末尾追加的方式寫入文件，即便出現問題，aof-check-aof也可以修復文件。同時aof提供了重寫策略，來優化aof文件

　　　　　　3.aof有序保存了對數據庫執行寫的操作，以redis協議數據保存，易於讀和解析，並且不小心執行了flushall，也可以移除aof文件末尾的flushall命令，恢復之前的狀態。

　　　 缺點：

　　　　　　1.對於相同的數據集來說，aof文件體積大於rdb文件的體積。

　　　　　　2.因為采用了同步策略，aof的速度相比rdb還是要慢一些。

　　兩種持久化的策略可以同時使用，也可以使用其中的一種，如果同時使用的時候，那麽Redis重啟時，會優先使用aof文件來還原數據。

<Redis> 入門五 持久化RBD/AOF