redis03

持久化

redis將全部數據保持在內存中，對數據的更新將異步地保存在磁盤中

快照

MySQL Dump ，Redis RDB

日誌

MySQL Binlog Hbase HLog Redis AOF

 

RDB的觸發方式

 

save同步
在save的同時，其餘命令會阻塞等待
若是存在老的RDB文件，會先建立一個臨時文件，而後對老文件進行替換
時間複雜度，O(n)

 

bgsave異步
調用bgsave後，會調用linux的fork()函數，建立一個子進程
若是存在老的RDB文件，會先建立一個臨時文件，而後對老文件進行替換
時間複雜度，O(n)
子進程名稱：redis-rdb-bgsave

save與bgsave的比較

 

經過配置自動進行RDB操做

內部至關於bgsave

save 900 1
save 300 10
save 60 10000

1 　　配置項                默認值       含義
2 dbfilename     　　　　dump.rdb     　　RDB快照文件名
3 dir             　　　　　./            RDB快照文件生成所在目錄
4 stop-writes-on-bgsave-error     yes         bgsave時發生錯誤是否中止寫入
5 rdbcompression            yes                RDB文件是否採用壓縮
6 rdbchecksum                yes                   是否對RDB進行校驗            

 

其餘觸發機制
主從複製時機的全量複製，master節點會執行bgsave
debug reload
shutdown
flushDB 、 flushAll

 

RDB缺點

耗時
耗性能
不可控，容易丟失數據

 

AOF

 

經過日誌方式將redis中的寫命令進行日誌記錄，保存在硬盤文件中

日誌記錄的實質是將寫命令寫在硬盤的緩衝區中，再根據相關策略把數據刷新到磁盤中

當redis服務器啓動時候，執行硬盤中的日誌文件以恢復redis中的數據

 

AOF的三種策略

always
執行每條寫命令都會將寫命令寫到磁盤中
不丟失數據，IO開銷大

everysec
每秒將數據從緩衝區刷到磁盤中，可能會丟失一秒的數據

no
寫命令什麼時候刷新的磁盤中，由操做系統來決定
不用管，不可控

 

AOF的重寫

減小磁盤佔用
加速AOF恢復速度
例如一萬次incr key 能夠重寫爲 set key 10000

 

bgrewriteaof

客戶端發送出一條bgrewriteaof命令後，redis會fork一個子進程完成AOF重寫操做邏輯

配置 　　　　　　　　　　 默認值 　　　　 　　　　含義
auto-aof-rewrite-min-size 　　64MB 　　　　　AOF文件重寫須要的尺寸，AOF多大時開啓重寫
auto-aof-rewrite-percentage   100 　　　　　　AOF文件增加率(當前AOF文件大小超過上一次重寫的 AOF、文件大小的百分之多少纔會重寫)

 

統計名 　　　　　　 含義
aof_current_size　　 AOF當前尺寸（單位：字節）
aof_base_size 　　    AOF上次啓動和重寫的尺寸（單位：字節）

原理
AOF重寫不會讀取老的AOF文件，而是根據當前服務器的狀態生成一份新的AOF文件，將老的AOF文件進行替換

 

1 配置項            取值        含義
2 appendonly        yes        開啓AOF
3 appendfilename   aof-${port}.aof    AOF文件名
4 appendfsync        everysec        AOF策略
5 dir            /redisDataPath    AOF文件所在目錄
6 no-appendfsync-no-rewrite    yes        在執行重寫時不進行AOF操做
7 auto-aof-rewrite-percentage    100        AOF文件增加率
8 auto-aof-rewrite-min-size    64MB        AOF文件重寫須要的尺寸

 

 RDB與AOF的比較

 

策略

 

RDB
關閉RDB自動執行配置
手動管理時進行RDB操做
在從節點打開自動執行配置，可是不宜頻繁執行RDB

AOF
建議打開，可是若是隻是純做爲緩存使用能夠不開
AOF重寫集中管理
everysec

 

最佳策略

小分片
　　例如設置maxmemory參數設置每一個redis只存儲4個G的空間，這樣各類操做都不會太慢
須要進行監控（硬盤、內存、負載、網絡）
機器須要有足夠的內存

 

fork操做

fork操做是一個同步操做，若執行較慢會阻塞redis主線程

執行時間與內存量相關：內存越大，耗時越長；虛擬機較慢，真機較快

查看fork執行時間，可作監控
info : latest_fork_usec 上一次執行fork的微秒數

 

改善fotk

優先使用物理機或者高效支持fork操做的虛擬化技術
控制Redis實際最大可用內存
合理配置Linux內存分配策略 vm.overcommit_memory = 1
默認這個值爲0，在內存比較低的時候，會發生fork阻塞
下降fork頻率：例如放寬AOF重寫自動觸發時機，沒必要要的全量複製

 

子進程開銷

CPU開銷： RDB和AOF都會生成文件，屬於CPU密集型
優化1：不作CPU綁定，不和CPU密集型的應用部署在同一臺服務器上
優化2：避免在單機多部署的場景大量發生AOF重寫

內存開銷：fork內存開銷，copy-on-write，子進程會共享父進程的物理內存頁，當父進程執行寫請求的時候會建立一個副本，此時會消耗內存。即父進程在大量寫入的時候，子進程開銷會比較大，建立副本。
優化1：防止單機多部署的時候發生大量的重寫
優化2：echo never > /sys/kernel/mm/transparent_hugepage/enabled
Linux內核的2.6.38版本中增長以上配置，支持大的內存頁的分配
內存頁分配越大，會提升建立副本頁的大小，影響性能

硬盤開銷：RDB與AOF文件寫入的場景，能夠集合iostat、iotop進行分析
優化1：不要和高硬盤負載服務部署在一塊兒，例如存儲服務、消息隊列
配置：no-appendfsync-on-rewrite = yes
根據寫入量決定磁盤類型：SSD
單機多實例持久化目錄能夠考慮分盤以及作資源限制，例如cgroup

 

 

AOF追加阻塞

​Redis在執行fsync的時候，redis爲了保證AOF文件安全性，會校驗上次fsync的時間是否大於2秒。若超過2秒，會發生阻塞。

​能夠經過Redis日誌進行定位：Asynchronous AOF fsync is taking too long (disk is busy?)

​能夠經過info persistence命令進行查看：每發生一次，aof_delayed_fsync 會增1

​優化方法能夠參考硬盤優化策略

 

 

 

 

 

 

 完