Redis采用fork子进程重写AOF文件时，有潜在的阻塞风险 1. fork子进程 fork子进程，fork这个瞬间一定是会阻塞主线程的（注意，fork时并不会一次性拷贝所有内存数据给子进程），**fork采用操作系统提供的写实复制(Copy On Write)机制，就是为了避免一次性拷贝大量内存数据给子进程造成的长时间阻塞问题**。

对于任何应用服务和组件，都需要一套完善可靠谱监控方案。 尤其redis这类敏感的纯内存、高并发和低延时的服务，一套完善的监控告警方案，是精细化运营的前提。 本文分几节，细说Redis的监控和告警： 1.Redis监控告警的价值 2.Redis监控的数据采集 3.Redis告警策略 4.基于Open Falcon的Redis监控告警方案

1、监控系统，可以从运营级别（基本配置即可），以及应用级别（二次开发，通过端口进行日志上报），对服务器、操作系统、中间件、应用进行全面的监控，及报警，对我们的系统正常运行的作用非常重要。 2、基础监控 CPU、Load、内存、磁盘、IO、网络相关、内核参数、ss 统计输出、端口采集、核心服务的进程存活信息采集、关键业务进程资源消耗、NTP offset采集、DNS解析采集，这些指标，都是open-falcon的agent组件直接支持的。

1. Linux运维基础采集项 做运维，不怕出问题，怕的是出了问题，抓不到现场，两眼摸黑。所以，依靠强大的监控系统，收集尽可能多的指标，意义重大。但哪些指标才是有意义的呢，本着从实践中来的思想，各位工程师在长期摸爬滚打中总结出来的经验最有价值。

Redis 3.2.3 crashed by signal: 11 服务宕机问题排查，现象是Redis执行bgsave 、bgrewriteaof、全量scan等操作都会出现崩溃

线上故障处理，需要将解析redis的aof文件的命令，然后排查故障原因。将aof文件转换为命令使用可以使用waoffle

CENTOS 安装NPM

linux中程序崩溃后，在 `dmesg -T`命令中可以看到程序崩溃时报的错误标记信息，如下代码中的`error 4`、 `error7`