分享一次因为Redis持久化超时导致服务器重启的事件

写在前面

记录一次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持久化。