寫在前面
記錄一次Redis持久化超時導致服務器重啓的系統事件。
建議首先閱讀 https://blog.csdn.net/zhouwenjun0820/article/details/105881313
1. 持久化監控
（1）可以通過指定命令【info persistence】查詢當前Redis實例持久化狀態，如下圖：
其中
【rdb_last_bgsave_time_sec】是上一次rdb快照的耗時，
【aof_delayed_fsync】是同步(save)AOF文件延遲（超過2秒）的累計次數。
（2）可以通過查詢日誌：
Asynchronous AOF fsync is taking too long(disk is busy?).writing the AOF buffer without waiting for fsync to complete. this may slow down Redis.
意思是：異步AOF文件同步耗時很長，磁盤很繁忙麼？
在不等待fsync完成的情況下寫入AOF緩衝區，這有可能降低Redis的性能。
我們的監控系統根據這兩個現象進行監控，如果監控到rdb耗時超過30秒或者aof fsync延遲累計持續增加，或者aof超時日誌，則說明Redis可能存在問題。
2. 超時現象
我們的Redis同時開啓了RDB和AOF兩種持久化模式。
監控系統於2019年7月13號開始監控到Redis RDB耗時超過30秒，甚至超過60秒，不斷有aof fsync超時日誌出現。
經查看Redis的內存使用從7月10號開始急速上升，經確認是某個key的過期時間設置過長（長達41天），而且每筆請求會新增一個key,而10號開始的營銷活動是這次告警的導火索。
3. 服務器宕機
在2019年8月13號，監控系統監控到某個Redis實例失聯，並且該服務器在凌晨異常重啓，經過查看系統重啓生成的coredump日誌（/backup/crash），發現重啓的原因是Redis進程處於狀態 D 的時間長達120秒，觸發了系統kernel panic。
coredump日誌：
這是因爲Redis的RDB耗時超過2分鐘導致的
4. 解決方案
臨時關閉RDB持久化。