四、redis之RDB和AOF持久化
持久化：將redis存放在內存的數據的更新異步備份到磁盤上
持久化方式：
快照：redis=》rdb、mysql=》dump
寫日誌：redis=》aof、mysql=》binlog
1.RDB（redis detabases）
1.1、同步快照（節省內存資源；redis服務屬於單線程，所以在快照過程中會出現阻塞現象）
client發送save命令，生成rdb二進制文件
1.2、異步快照（fork一個進程備份數據出現阻塞【很快，可忽略】、消耗內存、但redis服務不會出現阻塞現象）
client發送bgsave命令，生成rdb二進制文件
1.3、自動快照（不需要客戶端發送命令，redis服務根據在一定時間內改變數量判定是否需要快照。配置文件：save seconds changes）
save 900 1（900秒有1個數據改變時進行異步備份）
save 300 10（300秒有10個數據改變時進行異步備份）
save 60 10000（60秒有10000個數據改變時進行異步備份）
1.4、觸發機制-不容忽略方式
全量複製
debug reload
shutdown
1.5、RDB總結
rdb時redis內存到硬盤的快照，用於持久化
save通常會阻塞redis
bgsave不會阻塞redis，但是會fork新進程
save自動配置滿足任一就會被執行
有些觸發機制不容忽視
耗時耗性能，不可控，丟失數據
2.AOF（append only file）
1、aof三種策略
1.1：always（redis寫命令刷新到緩衝區，每條寫命令都把緩衝區fsync到硬盤，即：aof文件。不會丟失數據、IO開銷大）
1.2：everysec（【默認值】redis寫命令刷新到緩衝區，每秒把緩衝區fsync到硬盤，即：aof文件。宕機只會丟失1秒的數據、）
1.3：no（redis寫命令刷新到緩衝區，根據操作系統決定把緩衝區fsync到硬盤，即：aof文件。不用管，而不可控）
2、aof重寫（把過期、重複、無效進行去除，化簡）=》減少硬盤佔用量，加速回復速度
2.1：bgrewriteaof
客戶端發送bgrewriteaof命令，redis服務fork異步一個子進程進行aof重寫
2.2：aof重寫配置
2.2.1、auto-aof-rewrite-min-size（aof文件重寫需要的尺寸【配置】）
2.2.2、auto-aof-rewrite-percentage（aof文件增長率【配置】）
2.2.3、aof_current_size（aof當前尺寸（單位：字節）【統計】）
2.2.4、aof_base_size（aof上次啓動和重寫的尺寸【單位：字節】【統計】）
自動觸發時機(同時滿足)：
aof_current_size > auto-aof-rewrite-min-size、
（aof_current_size - aof_base_size）/ aof_base_size > auto-aof-rewrite-percentage
3、aof配置
appendonly yes|no （打開或關閉aof持久化）
appendfilename ”appendonly-${port}.aof“（設置aof文件名稱）
appendfsync everysec|always|no（aof同步策略）
dir ”保存文件地址（日誌|rdb|aof文件）“
no-appendfsync-on-rewrite yes|no（aof重寫時是否允許正常的aof-append操作）
auto-aof-rewrite-percentage 100（增長率）
auto-aof-rewrite-min-size 64mb（最小尺寸）
aof-load-trunted yes （是否忽略aof錯誤）
3、RDB與AOF區別和抉擇
1.區別
啓動優先級：rdb低、aof高；體積：rdb小、aof大；恢復速度：rdb快、aof慢；數據安全性：rdb丟數據、aof根絕策略而定；輕重：rdb重、aof輕；
2.抉擇
小分片
緩存或者存儲
監控（硬盤、內存、負載、網絡）
足夠的內存
4.開發運維問題
1.fork線程
1.1：同步操作
1.2：與內存息息相關：內存越大，耗時約長（與機器類型有關）
1.3：info:lastest_fork_usec（查詢fork時間）
1.4：改善fork
1.4.1、有限使用物理機或者高校fork操作的虛擬技術
1.4.2、控制redis實例最大可用內存：maxmemory
1.4.3、合理配置linux內存分配策略：vm.overcommit_memory=1
1.4.4、降低fork頻率：例如放跨u你AOF重寫自動觸發時機，不必要的全量複製
2.子進程外開銷與優化
2.1：CPU
~開銷：RDB與AOF文件生成，屬於CPU密集型
~優化：不做CPU綁定，不和CPU密集型部署
2.2：內存
~開銷：fork內存開銷，copy-on-write
~優化：echo never >
2.3:硬盤
~開銷：AOF和RDB文件寫入，可以i結合iostat，iotop分析
~優化：不要和高硬盤負載服務部署在一起：存儲服務，消息隊列等；no-appendsync-on-rewrite=yes；根據寫入量決定磁盤類型：例如ssd；單機多實例持久化文件目錄可以考慮分盤
3.AOF追加阻塞
3.1：阻塞定位
3.1.1、redis日誌
3.1.2、info Persistent（歷史的累計過程）
3.1.3、通過硬盤查看使用IO情況