## 一、持久化的作用 * 什么是持久化 * 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 * 最佳策略 * 小分片 - * 緩存或者存儲 - 根據緩存或存儲的特性決定使用那種策略 * 監控（硬盤、內存、負載、網絡） * 足夠的內存