一站式學習Redis， 從入門到高可用分散式實踐-05-06持久化
阿新 • • 發佈：2022-04-12
redis持久化的取捨和選擇
- 什麼是持久化
- redis所有資料儲存在記憶體當中，對資料的更新將非同步儲存到磁碟上
- 持久化方式
- 快照 --- redis RDB(mysql dump)
- 寫日誌 --- redis AOF (mysql binlog)(hbase hlog)
- RDB
- 觸發機制-三種方式
save同步，會造成redis客戶端阻塞，檔案策略：如果存在老的rdb檔案，新的會替換掉老的檔案
bgsave非同步，不會造成redis客戶端阻塞，檔案策略：與save相同
自動
-
save與bgsave的區別
配置檔案:
dbfilename dump.rdb
最佳配置： -
rdb持久化的三種方式，save,bgsave，配置檔案設定自動備份時間
-
RDB總結：
- rdb是redis記憶體到硬碟的快照，用於持久化
- save通常會阻塞redis
- bgsave不會阻塞redis,但是會fork一個新的程序
- save自動配置滿足任意一個條件就會被執行
- 有些觸發機制不容忽視，比如主從複製、shutdown
- redis的持久化方式AOF
- RDB現存問題：
耗時、好效能
不可控，容易丟失資料
- AOF的執行原理
- 建立：沒當redis有更新命令時就會寫入aof檔案
- 恢復：當redis重啟時就會把aof文中中的命令重新執行一遍，所有資料就恢復到記憶體了
- AOF的三種策略
- always
- everysec
- no
redis寫命令先重新整理到緩衝區，然後每條命令fsync到硬碟（always）
redis寫命令重新整理到緩衝區，然後每隔一秒把緩衝區fsync到硬碟（everysec）
redis寫命令重新整理到緩衝區，然後os決定何時吧緩衝區fsync到硬碟（no）
-
always、everysec、no優缺點比較
-
AOF重寫
- AOF重寫的作用：減少磁碟的佔用量，加速恢復速度
- AOF重寫實現的兩種方式：bgrewriteaof、aof重寫配置
-
aof的bgrewriteaof
aof的重寫就是將記憶體中的資料進行回溯 -
aof重寫配置
-
AOF重寫流程
-
AOF配置
-
AOF實驗
config set appendonly yes # 開啟aof
bgrewriteaof
開啟data目錄下的appendonly.aof檔案檢視，發現新增的命令被bgrewriteaof重寫了
- RDB與AOF對比
18 RDB的最佳策略
"關"、集中管理、主從，從開？
-
AOF的最佳策略
"開":快取和儲存
AOF重寫集中管理
AOF策略選擇everysec -
最佳策略
小分片、快取或者儲存、監控（硬碟、記憶體、負載、網路）、足夠的記憶體
常見的持久化開發運維問題
- fork操作
- 同步操作
- 與記憶體量息息相關：記憶體越大，耗時越長（與機器型別有關）
- info: latest_fork_usec
1.1 改善fork
- 優先使用物理機或者高效支援fork操作的虛擬化技術
- 控制redis例項的最大可用記憶體maxmemory
- 合理配置linux記憶體分配策略，vm.overcommit_memory=1
- 降低fork頻率，例如放寬aof重寫自動觸發時機，不必要的全量複製
- 程序外開銷（子程序開銷和優化）
2.1 CPU開銷
- RDB和AOF檔案生成，屬於CPU密集型
- 優化：不做CPU繫結，不和CPU密集型部署
2.2 記憶體 - 開銷：fork記憶體開銷，copy-on-write
2.3 硬碟 - 開銷：AOF和RDB檔案的寫入，可以結合iostat iotop分析
2.4 硬碟優化 - 不要和高硬碟負載服務部署在一起：儲存服務，訊息佇列等
- no-appendfsync-on-rewrite yes
- 根據寫入量決定磁碟型別：ssd
- 單機多例項持久化檔案目錄可以考慮分盤
- AOF追加阻塞
3.1 AOF阻塞定位
- redis日誌