本文講解知識點
持久化的簡介
RDB
AOF
RDB與AOF的區別
持久化應用場景
對於持久化這個功能點，其實很簡單沒有那麼複雜
Redis持久化
- 演示環境
- 1. 持久化簡介
- 2. RDB
- 2-1 RDB啓動方式 -- save命令
- 2-2 RDB啓動方式 -- save指令相關配置
- 2-3 RDB數據恢復
- 2-4 RDB -- save指令工作原理
- 2-5 RDB -- bgsave指令工作原理
- 2-5 RDB -- 配置文件自啓動
- 3. AOF
- 3-1 AOF概念
- 3-2 AOF寫數據過程
- 3-3 AOF寫數據的三種策略
- 3-4 AOF功能開啓
- 3-5 AOF寫數據出現的問題
- 3-6 AOF重寫
- 3-7 AOF重寫作用
- 3-8 AOF重寫規則
- 3-9 AOF手動重寫
- 3-10 AOF手動重寫工作原理
- 3-11 AOF自動重寫
- 3-11 AOF工作流程和重寫流=流程
- 4. RDB和AOF區別
演示環境
centos7.0
redis4.0
redis存放目錄：/usr/local/redis
redis.conf存放目錄：/usr/local/redis/data
1. 持久化簡介
redis的所有數據都是保存在內存中，redis崩掉數據會丟失。redis持久化就是把數據保存在磁盤上。利用永久性存儲介質將數據進程保存，在特定的時間將保存的數據進行恢復的工作機制稱爲持久化。
持久化過程保存的是什麼呢？
第一種快照形式，存儲數據結果，關注點在數據，也就是下文會講到的RDB
第二種操作過程，存儲操作過程，存儲結構複雜，關注點在數據的操作過程，也就是下文會講到的AOF
2. RDB
2-1 RDB啓動方式 – save命令
下圖是redis.conf的配置信息，在執行完save後會生成一個dump.rdb的文件
現在我們設置一個值，然後save一下，在/usr/local/redis/data下就會有一個dump6379.rdb的一個文件
2-2 RDB啓動方式 – save指令相關配置
- dbfilename dump6379.rdb ：設置本地數據庫文件名，默認值爲dump.rdb
- dir：存儲rdb文件的路徑
- rdbcompression yes ：設置存儲至本地數據庫時是否壓縮數據，默認爲yes，採用lzf壓縮
- rdbchecksum yes：設置是否進程RDB文件格式校驗，該校驗過程在寫文件和讀文件過程均進行
2-3 RDB數據恢復
其實這個數據恢復相對於其他關係型數據庫恢復基本就不用操作什麼。只需要重新在啓動就好了
2-4 RDB – save指令工作原理
此圖來源於網絡視頻。
save指令的執行會阻塞當前redis服務器，直到當前RDB過程完爲止，有可能會造成長時間的阻塞。這個指令在工作過程中基本以被廢棄不在使用。會以bgsave全部代替
2-5 RDB – bgsave指令工作原理
當在redis執行了bgsave後會直接返回一個Background saving started
這個時候我們在看一下日誌文件，bgsave命令是針對save阻塞問題做的優化
2-5 RDB – 配置文件自啓動
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
save 【時間】 【key改變數量】
也就是說在300秒有10個key值發生變化了，就會在後臺執行bgsave
3. AOF
3-1 AOF概念
AOF持久化：以獨立日誌的方式記錄每次寫命令，重啓時在重新執行AOF文件中命令達到數據恢復的目的。與RDB相比可以簡單描述爲記錄數據產生的過程
AOF的主要作用是解決了數據持久化的實時性，目前已經是redis持久化的主流方式
3-2 AOF寫數據過程
執行一條redis命令
redis的AOF會把命令刷新緩衝區
然後根據一定的策略同步的到redis.conf配置的.aof文件中
3-3 AOF寫數據的三種策略
- always：每次寫入操作均同步到AOF文件中，數據零誤差，性能較低，不建議使用
- everysec：每秒將緩衝區中的指令同步到AOF文件中，數據準確性較高，性能較高，建議使用，也是默認配置。但是在系統突然宕機的情況下回丟失1秒內的數據
- no：由操作系統控制每次同步到AOF文件的週期，整體過程不可控
3-4 AOF功能開啓
- 配置：
appendonly yes|no - 作用：是否開啓AOF持久化功能，默認爲不開啓狀態
- 配置：
appendfsync always| everysec | no - 作用：AOF寫數據策略
- 配置：appenfilename filename
- 作用：AOF持久化文件名，默認名爲appendonly.aof
然後使用重啓redis服務，就可以在usr/local/redis/data目錄下可以看到appendonly.aof文件了
然後我們在redis客戶端執行一條命令，在來查看一下。可以看到數據都會存入appendonly.aof這個文件中。
3-5 AOF寫數據出現的問題
我們先看一個案例，我們重複設置了name這個key後，打開appendonly.aof文件查看，可以看到有三個操作，但是這三個操作我們都是修改的一個key啊！我們只保存最後一個key不行嗎？帶着這個疑問，我們在繼續往下看
3-6 AOF重寫
隨着命令不斷寫入AOF，文件會越來越大，爲了解決這個問題，redis引入了AOF重寫機制壓縮文件體積。AOF文件重寫是將redis進程內的數據轉化爲寫命令同步到新AOF文件的過程。簡單說就是將對同一個數據的若干條命令執行結果轉化爲最終結果數據對應指令的執行記錄。
如在上邊我們執行了三次 set name 指令，但是我們最終就只需要最後一次執行的數據。也就是我們只需要最後一次執行記錄即可。
3-7 AOF重寫作用
- 降低磁盤佔用量，提高磁盤利用率
- 提高持久化效率，降低持久化寫時間，提高IO性能
- 降低數據恢復用時，提高數據恢復效率
3-8 AOF重寫規則
- 進程內已超時的數據不再寫入文件
- 忽略無效指令，重寫時使用進程內數據直接生成，這樣新的AOF文件值保留最終數據的寫入命令。如del指令，
hdel，srem。 多次設置一個key值等 - 對同一數據的多條寫入命令合併爲一條命令：如
lpush list a lpush lsit b lpush list c可以轉化爲lpush list a b c。但是爲了防止數據量過大造成客戶端緩衝區溢出，對list，set，hash，zset類型每條指令最多寫入64個元素
3-9 AOF手動重寫
指令：bgrewriteaof
接着我們3-5的問題，我們在命令行執行bgrewriteaof指令然後查看appendonly.aof文件
當執行完後會發現文件變小了，文件裏也就只有一條指令了
3-10 AOF手動重寫工作原理
3-11 AOF自動重寫
配置：auto-aof-rewrite-percentage 100 | auto-aof-rewrite-min-size 64mb
觸發對比參數：aof_current_size | aof_base_size
當aof_current_size > auto-aof-rewrite-min-size 64mb 會啓動重寫
此圖來源於網絡
3-11 AOF工作流程和重寫流=流程
4. RDB和AOF區別
-
對數據非常敏感，建議使用默認的AOF持久化方案
- AOF持久化策略使用everysecond, 每 秒 鍾fsync-次•該策略redis仍可以保持很好的處理性能，當出現問題時， 最 多丟失0-1秒內的數據.
- 注意：由於AO文件存儲體積較大，且恢復速度較慢
-
數據呈現階段有效性，建議使用RDB持久化方案
- 數據可以良好的做到階段內無丟失（該階段是開發者成運維人手工維護的），且恢復速度較快，階段點數據恢復通常採用RDB方案
- 注 意 ： 利 用RDB實現緊促的數據持久化會使Redis降的很低
-
綜合對比
- RDB與AOF的選擇實際上是在做一種權衡，每種都有利有弊
- 如不能承受數分鐘以內的數據丟失，對業努數據非常敏感，選用A0F
- 如能承受數分鐘以內的數據丟失，旦追求大數據集的恢復速度，選用RDB
- 災難恢復使用RDB
- 雙保險策略，同時幵啓RDB和AOF, 重啓後，Redis優先使用A0F來恢復數據，降低丟失數據的量