redis3 持久化RDB /AOF

redis 的持久化 ： ADB AOF

redis 是一個內存數據庫，如果不想辦法將內存中的數據持久化到磁盤中，一旦數據庫進程結束，數據就會全部丟失。所以一定要將內存中的數據以一定的策略持久化到磁盤上。再次啓動Redis 的時候就是用磁盤上的數據來還原數據。

RDB ：

幹什麼：
將一段時間間隔之後的內存快照（snapshot）保存到磁盤中；恢復數據的時候將數據從磁盤中從新讀到內存中。
有關這一部分的配置：SNAPSHOT

如何觸發RDB

1. 根據配置文件的配置，自動進行持久化

   # Save the DB on disk:
   #   save <seconds> <changes>
   
   #   save ""   # 如果不想使用自動ADB 就配置爲空字符串
   
   save 900 1  # 900 s 內有一個key 被修改就會觸發一次ADB
   save 300 10  # 300 s 內有十次key 修改就會觸發ADB
   save 60 10000   # 60s 內有10000 次修改
   
   在測試的時候也可以自己對觸發的時間點進行修改：格式： save <seconds> <changes>
   

   例如： 300s 內如果你修改了10 次key 那麼300s 時間一到 ，就會將此時的內存快照持久化到磁盤中。

2. 手動觸發

   1. 執行save,bgsave 指令，會立即執行持久化;save :只管存儲，在持久化結束（dump.rdb 文件創建結束）之前，其他的請求都會阻塞。bgsave : 會異步的執行持久化，redis 依然能響應客戶端的請求
   2. flushall ： 此時備份的數據是空的

RDB如何實現持久化
Redis 會單獨的創建（fork）一個子線程完成持久化，首先會將數據寫到一個臨時文件中，待持久化過程都結束之後再用這個臨時文件替換之前持久化好的文件。在整個過程中，主進程不會進行任何的I/O 操作，這樣保證了主線程的高效性。（bgsave 是通過創建fork 子線程，但是save 是在當前的服務線程中完成持久化）
如果是需要大規模的數據恢復，且對數據恢復的完整性要求不高，那麼ADB的性能要高於AOF。ADB的一個缺點在於：如果在最後一個持久化的時候剛好發生了異常，那麼最後一次持久化的數據可能會丟失
fork : 複製一個和當前線程一樣的線程完成持久化，新進程中的所有數據都是和原線程一樣的，稱爲原線程的主線程。但是這樣的複製，如果你的主線程十分大，那麼在存儲上的空間消耗就十分大。
ADB 持久化的結果就是生成一個 dump.rdb 文件
相關的配置：

# The filename where to dump the DB ： 持久化文件名
dbfilename dump.rdb

# Note that you must specify a directory here, not a file name. 持久化文件的存儲位置，一個目錄而不是文件名
dir ./

# permissions, and so forth.
stop-writes-on-bgsave-error yes
#  這一項設置爲yes 之後。當redis 的持久化出現問題之後，redis 的寫入也會直接停止。

如何恢復數據（文件載入和數據恢復）：
在實際的使用中會將數據備份另外的機器上，當前服務機器出現物理破壞導致數據再也無法恢復。

一般Redis啓動的時候會自動載入dump.db。如果將備份文件(dump.rdb)移動到 redis 的安裝目錄啓動服務即可。（config get dir 獲取目錄）。服務器在載入rdb 文件的時候服務器一直處於阻塞狀態。

總結：
優勢：

1. 適合大規模的數據備份
2. 對數據的一致性要求不高

劣勢：

1. fork 新的線程處理持久化，內存的消耗會變大
2. 最後一次的數據備份可能會丟失

停止ADB 配置save ""/或者命令取消：redis-cll config set save "" 但是一般不會

AOF

AOF 主要是解決ADB產生的一些問題,例如最後一次數據丟失。但是在實際操作中最後一次數據丟失也沒有太大的影響，畢竟有運維人員專門對數據進行恢復。比如你的redis 15 分鐘進行一次ADB，找回15 分鐘的數據還是不難的。

幹什麼：
Redis 每進行依次寫操作就會把該命令寫入aof_buf 一個緩存區中，在不同的同步時機設置下把aof_buf 中的內容寫入磁盤中(aof 文件中)。redis 在重啓的時候會重構數據，就是將aof 文件中的寫指令都再執行一遍。

在啓動的時候如果dump.rdb , appendonly.aof 都存在，那麼首先會加載.aof
修復aof 文件：redis-check-aof --fix appendonly.aof 命令執行會自動修復文件

aof 模式：
aof 的相關配置：

# 默認的是關閉的
appendonly no

#默認設置的文件名
appendfilename "appendonly.aof"

#數據持久化的時機
# appendfsync always   # 只要改變了數據就要進行持久化，這樣I/O 操作頻繁，效率會極低
appendfsync everysec # 默認使用；異步操作，每隔一秒會將aof_buf 中的數據寫入磁盤，就算數據丟失也只丟失一秒的
# appendfsync no # 只管將指令寫入aof_buf 不管何時進行同步

文件載入/數據恢復：

重寫：Rewrite
爲了解決AOF文件體積不斷膨脹的策略
aof 是追加的方式，文件會越來越大，爲了避免這種情況的出現，新增重寫機制。當文件的大小達到某個閾值的時候，AOF 就啓動文件壓縮，只保留可以恢復文件的最小指令集，使用命令 bgrewriteaof
重寫原理： fork 出一條新的線程進行重寫任務
觸發重寫的時機:

auto-aof-rewrite-percentage 100  # 比上一次rewrite 後的大小大一倍
auto-aof-rewrite-min-size 64mb   # 並且超過64mb

redis 會記錄上一次重寫時aof 的大小，默認配置是當AOF文件大小比上一次rewrite 後的大小大一倍且文件大小大於64mb 的時候觸發重寫。

劣勢： aof的文件要比rdb 的文件大很多

如果在數據庫中開啓了AOF功能會首先使用AOF還原