《我是程序媛》系列，这是由一次故障引发的，对php-fpm信号的学习，不关注故障的同学可直接跳到涨姿势的部分。
故障回顾
故障时间：2017-02-25 周六 08：56-10：20左右
故障现象：app找房不可用，后台502
暴露问题：没有报警，没有健康检查，没有兜底，没有降级
故障恢复
运维同学说：“标准流程，重启！” 就 T_T了 (一会再说这的问题)
故障原因
- 周六之前在监控系统观察，发现每天凌晨都有502的问题；
- 所以查了下发现每天三点都有重启的动作（截图如下）；
- 修改restart为reload；
- reload脚本有bug，信号发错，导致master进程被干掉，子进程2048个请求后，自动退出了（so，3点的动作8点多才出现问题，截图如下）；
涨姿势
php-fpm的进程相关，见上篇《php-fpm解读-进程管理的三种模式》
-
php-fpm的信号
- SIGUSR1信号
功能：重新打开日志
作用：提供了一种手段，防止单个日志文件过长
执行步骤：
1、 master进程重新打开error_log，error_log是全局log，所有pool共享
2、 master进程重新打开每个pool的access_log，同一个pool中的子进程会写入同一个access_log
3、 master通过给子进程发送SIGQUIT信号的方式，平滑关闭所有的子进程
4、 每个worker退出后，master会重新fork子进程
为什么要关闭所有的子进程呢？因为master进程重新打开access_log日志文件，只是对master有效，只有重启子进程，子进程才能真正的感知到access_log的变化，才能写到新的日志里面
- SIGUSR2信号
功能：重启fpm，包括master和worker
作用：就是为了重启
执行步骤：
1、 master通过给子进程发送SIGQUIT信号的方式，平滑关闭所有的子进程
2、 如果过一段时间，有些子进程还没退出，给子进程发送SIGTERM信号，强制关闭子进程
3、 如果还没关闭，给子进程发送SIGKILL信号，强制关闭
4、 等所有的子进程退出后，master重新启动
- SIGQUIT信号
功能：平滑关闭fpm
作用：关闭fpm，不影响正在处理的请求，等处理完正在处理的请求后，子进程才退出
执行步骤：
1、 Master通过给子进程发送SIGQUIT信号的方式，关闭所有的子进程
2、 如果过一段时间，有些子进程还没退出，给子进程发送SIGTERM信号，强制关闭子进程
3、 如果还没关闭，给子进程发送SIGKILL信号，强制关闭
4、 等所有的子进程退出后，master退出
为什么叫平滑关闭？因为master和worker都对SIGQUIT进行了处理，master收到SIGQUIT信号时，它也会给worker发SIGQUIT信号，worker对SIGQUIT信号的处理方式就是，处理完手头的活儿才关闭，所以不影响当前请求
- SIGTERM/SIGINT信号
功能：强制关闭fpm
作用：关闭fpm，方法暴力，会影响当前请求
执行步骤：
1、 master通过给子进程发送SIGTERM信号的方式关闭子进程
2、 如果过一段时间，有些子进程没关闭，master给子进程发送SIGKILL信号，强制关闭
3、 等所有子进程退出后，master退出
为什么叫暴力退出？因为worker进程没有处理SIGTERM和SIGKILL信号，当收到master发来的这些信号后，子进程会被os直接干掉。
注意：fpm对外只处理了上面5个信号，所有其他信号都采用默认行为，默认行为有可能会导致master直接退出。其他参见源码 https://github.com/php/php-src/blob/e3feeba3aedd8e4347fefa315effd7d4f9fa0ca1/sapi/fpm/fpm/fpm_signals.c
老司机经验
- 启动脚本一定要从官方下载，运维小哥别自己搞了；
- 发生故障，千万别重启，而是摘机器，保留现场；
- 核心业务一定要多机器，以免发生问题，只有两台，摘掉一台又怕扛不住；
- 所有研发一定要对自己的系统特别了解，跑了什么？怎么跑的？配置是什么?日志在哪里？
- 每次故障都要复盘清楚，不要不了了之（接下来：运维去测试下，日志切割不用动php看行不行；运维加对php-fpm的监控）；
- 报警（以后业务报警研发加，系统级报警运维加）；
- 健康检查（这次nginx的故障转移只加了500,503,404，所以502的出了问题）；
