## 一、持久化的作用
* 什么是持久化
* redis所有數據保存在內存中,對數據的更新將異步地保存到磁盤上。
* 持久化方式
* 快照 - 某事某點數據的完整備份
* MySQL Dump
* Redis RDB
* 寫日志 - 只要有操作就記錄到日志中
* MySQL Binlog
* Hbase HLog
* Redis AOF
## 二、RDB
* 什么是RDB
* 通過一條命令將redis內存中的數據完整生成一個快照保存到硬盤當中,也就是RDB文件(二進制),進行持久化。
* 對redis進行重啟,可以加載 RDB文件,進行恢復。
* 觸發機制-主要三種方式
* save 同步
* 向redis發送一個save命令,創建RDB文件,會造成redis阻塞。
* 文件策略:如存在老的RDB文件,新替換老。
* 負責度:O(N)
* bgsave 異步
* 在redis主進程生產fork() 子進程,創建RDB文件
* 如果fork 慢,會阻塞主進程。非常快的情況不會阻塞主進程。
* 自動
* 默認配置
| 配置 | seconds | changes |
| --- | --- | --- |
| save | 900 | 1 |
| save | 300 | 10 |
| save | 60 | 10000 |
當900秒內有1條修改則執行save,當300秒內有10條修改則執行save,當60秒內有10000條修改則執行save
| 配置 | 參數 | 說明 |
| --- | --- | --- |
| dbfilename | dump.rdb | 生產的文件名 |
| dir | ./ | 保存的文件路徑 |
| stop-writes-on-bgsave-error | yes | 發生錯誤是否停止寫入 |
| rdbcompression | yes | 是否采用壓縮格式 |
| rdbchecksum | yes | 是否進行檢驗 |
* 推薦配置
| 配置 | 參數 |
| --- | --- |
| dbfilename | dump-${port}.rdb |
| dir | /bigdiskpath |
| stop-writes-on-bgsave-error | yes |
| rdbcompression | yes |
| rdbchecksum | yes |
* save 與 bgsave 的不同
| 命令 | save | bgsave |
| --- | --- | --- |
| IO類型 | 同步 | 異步 |
| 阻塞? | 是 | 是(阻塞發生在fork) |
| 復雜度 | O(n) | O(n) |
| 優點 | 不會消耗額外內存 | 不阻塞客戶端命令 |
| 缺點 | 阻塞客戶端命令 | 需要fork,消耗內存 |
* 觸發機制-不容忽視方式
* 全量復制,即主從復制
* debug reload,發生錯誤時需建立RDB
* shutdown,重啟時建立RDB
* 總結
* RDB是Redis內存到硬盤的快照,用于持久化。
* save通常會阻塞Redis。
* bgsave不會阻塞Redis,但是會fork新進程。
* save自動配置滿足任一條件就會被執行。
* 有些觸發機制不容忽視
## 三、AOF
* RDB有什么問題
* 耗時、耗性能
* 需要把所有數據dumo到磁盤中,耗時O(n)的過程
* fork() : 消耗內存,copy-on-writh策略
* Disk I/O : IO性能消耗
* 不可控、丟失數據
| 時間戳 | save |
| --- | --- |
| T1 | 執行多個寫命令 |
| T2 | 滿足RDB自動創建的條件 |
| T3 | 再次執行多個寫命令 |
| T4 | 宕機 |
當T1時間點執行了很多寫命令,在T2時間點滿足RDB自動創建的條件,T3時間點又執行了很多寫命令,T4時間點宕機了,T3-T4時間段的寫入命令會丟失。
* AOF運行原理
* 創建 -- 以寫日志的方式把每一條寫命令追加到AOF文件當中
* redis在執行寫命令時,會寫到硬盤的緩沖區當中,緩沖區會根據一些**策略**把寫命令的日志刷新到磁盤當中
* 恢復 -- 當發生宕機時,重啟之后將AOF文件載入到Redis當中,進行數據恢復。
* AOF的三種策略
* always
* 寫每條命令都會fsync到磁盤
* everysec
* 每秒把緩沖區 fsync 到磁盤,出現故障有可能會丟失一秒的數據
* no
* 根據操作系統決定,操作系統說什么時候 刷,就什么時候刷。
| 命令 | always | everysec | no |
| --- | --- | --- | --- |
| 優點 | 不丟失數據 | 每秒一次 fsync 丟1秒數據 | 不用管 |
| 缺點 | IO開銷較大,一般的 sata 盤只有幾百 TPS | 丟1秒數據 | 不可控 |
* AOF重寫
* 把過期的、沒有用的、重復的以及可以優化的命令進行化簡,化簡為一個很小的AOF文件。
* 減少硬盤占用量
* 加速恢復速度
* AOF重寫實現的兩種方式
* bgrewriteaof
* 由客戶端發送 bgrewriteaof 命令到服務端,redis接收到命令后會 fork 出一個子進程,來完成AOF重寫。
* AOF重寫配置---實現自動重寫
| 配置名 | 含義 |
| --- | --- |
| auto-aof-rewrite-min-size | AOF文件重寫需要的尺寸 |
| auto-aof-rewrite-percentage | AOF 文件增長率 |
| 統計名 | 含義 |
| --- | --- |
| aof_current_size | AOF當前尺寸(單位:字節) |
| aof_base_size | AOF上次啟動和重寫的尺寸(單位:字節) |
* 自動觸發時機
* 當前尺寸 > 最小尺寸
* (當前尺寸 - 最小尺寸) / 最小尺寸 > 增長率
* 配置
| 命令 | 配置 | 說明 |
| --- | --- | --- |
| appendonly | yes | 開打AOF功能 |
| appendfilename | appendonly-${port}.aof | AOF生產的文件名 |
| appendfsync | everysec | 同步的策略 |
| dir | /bigdiskpath | 保存的目錄 |
| no-appendfsync-on-rewrite | yes | 是否在重寫的時候,關閉 AOF 的 appen操作,如果不關閉有可能會導致數據丟失,這里是 yes ,重寫時不做其他操作 |
| auto-aof-rewrite-percentage | 100 | 增長率 |
| auto-aof-rewrite-min-size | 64mb | 最小尺寸 |
* RDB和AOF抉擇
| 命令 | RDB | AOF |
| --- | --- | --- |
| 啟動優先級 | 低 | 高 |
| 體積 | 小 | 大 |
| 恢復速度 | 快 | 慢 |
| 數據安全性 | 丟數據 | 根據策略決定 |
| 操作的輕重 | 重,因為它要操作全部的redis數據 | 輕,日志追加的方式 |
* RDB最佳策略
* “關”- 在主從會用到
* 集中管理 - 如果需要按天按小時備份數據,是個不錯的選擇。
* 主從,從開?
* AOF最佳策略
* “開”:緩存和存儲 -- 如果只當緩存可以關掉
* AOF重寫集中管理
* everysec
* 最佳策略
* 小分片 -
* 緩存或者存儲 - 根據緩存或存儲的特性決定使用那種策略
* 監控(硬盤、內存、負載、網絡)
* 足夠的內存