概述：對于內存級的KV數據庫來說，將數據定時持久化到磁盤時一個必要的操作，因為一旦斷電或down機，就可能導致存儲在內存中的數據丟失，顯然這不是我們能接受的，對于kv數據庫來說，我們用得最多的無非就是memcached、TT 、etcd、redis等，而對于redis來說，相信目前已是it項目中使用最常見的緩存KV數據庫了。那么它有什么策略實現數據的持久化操作呢？ 下面就一起來看看吧。
Redis有兩種持久化方式，分別是RDB和AOF , 其中rdb是以間隔時間內定義key變化操作數來觸發數據持久化；而oaf是以配置持久化區間來操作持久化動作。
RDB持久化：（默認持久化方式）
在指定時間間隔內，將內存中的數據集快照寫入磁盤，恢復時是將快照文件直接讀到內存中，來達到恢復數據的。在默認情況下， Redis 將數據庫快照保存在名字為 dump.rdb 的二進制文件中。通過觸發快照的形式，來做到將指定時間間隔內的數據持久化到dump.rdb。
RDB持久化的redis.conf 配置項：
save 900 1
save 300 10
save 60 1000
RDB優點與缺點：
rdb是保存一個文件，顯然恢復時會方便快速，另外是觸發機制類型，明顯寫入磁盤不會太頻繁； 但缺點也很明顯，在數據要求可靠性和一致性很高時，存在數據丟失的情況，原因是rdb使用的是間斷性或階段性的觸發式持久化，可能會數據沒持久化前故障，導致數據丟失。
AOF持久化 （默認不開啟）
以日志的形式記錄Redis每一個寫操作,將Redis執行過的所有寫指令記錄下來（讀操作不記錄），只許追加文件不可以改寫文件，redis啟動之后會讀取Appendonly.aof文件來實現重新恢復數據，完成恢復數據的工作。默認不開啟，需要將redis.conf中的appendonly no改為yes后，重新啟動Redis。
AOF持久化的redis.conf 開啟配置項目 ：
appendonly yes
AOF持久化策略方式：
appendfsync always:每修改同步，每一次發生數據變更都會持久化到磁盤上，性能較差，但數據完整性較好。
appendfsync everysec: 每秒同步，每秒內記錄操作，異步操作，如果一秒內宕機，有數據丟失。
appendfsync no:不同步。
數據恢復：
重啟Redis時，如果dump.rdb與appendfsync.aof同時都存在時，Redis會自動讀取appendfsync.aof文件，通過該文件中對數據庫的日志操作，來實現數據的恢復。當然如果該文件被破壞，我們可以通過redis-check-aof工具來修復，如redis-check-aof --fix能修復破損的appendfsync.aof文件，當然如果dump.rdb文件有破損，我們也可以用redis-check-rdb工具來修復，如果appendfsync.aof文件破損了，是啟動不了客戶端的，也就是無法完成數據的恢復。
AOF優點與缺點：
appendfsync always: 每修改同步，每一次發生數據變更都會持久化到磁盤上，性能較差，但數據完整性較好。
appendfsync everysec: 每秒同步，每秒內記錄操作，異步操作，如果一秒內宕機，有數據丟失。
appendfsync no: 不同步。
appendfsync.aof文件要大于dump.rdb，如果aof同步文件持久化，會實時操作磁盤，因此會消耗一定的性能。 恢復速度方面aof會比rdb慢。
關于aof重寫機制：
當AOF文件一直被追加，這就可能導致AOF文件過于龐大。因此，為了避免這種狀況，Redis新增了重寫機制，當AOF文件的大小超過所指定的閾值時，Redis會自動啟用AOF文件的內容壓縮，只保留可以恢復數據的最小指令集，可以使用命令bgrewiteaof。
觸發機制：Redis會記錄上一次重寫時的AOF大小，默認配置是當AOF文件大小是上一次的一倍并且大于64m時，會觸發從寫機制。
例如配置：
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
