看了一下，发现自己可能还是没有太理解nginx下的php-fpm工作方式，所以再在网上找了些文章看了下，主要由几个疑问推广开来：
1.nginx杀掉master之后还能否接受请求
2.nginx是worker进程来抢还是master进程来分配
那php对应的又是什么情况呢？
参考1:
php-fpm是 FastCGI 的实现，并提供了进程管理的功能，包含master 和 worker 两种进程。
- master 创建并监听socket,fork多个woker进程，通过共享内存获取worker的状态，进而通过信号控制worker进程
- worker 自由accept cgi请求，
- master通过共享内存获取worker进程的信息，比如worker进程当前状态、已处理请求数等，当master进程要杀掉一个worker进程时则通过发送信号的方式通知worker进程。
网上很多php-fpm的文章都说master监听端口,然后再分配给worker处理,这个是不正确的,fpm的master进程与worker进程之间不会直接进行通信，worker 自由accept cgi请求。
作者：周焱
链接：https://juejin.im/post/6844903704735449102。
参考3:nginx的worker进程机制
worker进程又是如何处理请求的呢？我们前面有提到，worker进程之间是平等的，每个进程，处理请求的机会也是一样的。当我们提供80端口的http服务时，一个连接请求过来，每个进程都有可能处理这个连接，怎么做到的呢？首先，每个worker进程都是从master进程fork过来，在master进程里面，先建立好需要listen的socket之后，然后再fork出多个worker进程，这样每个worker进程都可以去accept这个socket(当然不是同一个socket，只是每个进程的这个socket会监控在同一个ip地址与端口，这个在网络协议里面是允许的)。一般来说，当一个连接进来后，所有在accept在这个socket上面的进程，都会收到通知，而只有一个进程可以accept这个连接，其它的则accept失败，这是所谓的惊群现象。当然，nginx也不会视而不见，所以nginx提供了一个accept_mutex这个东西，从名字上，我们可以看这是一个加在accept上的一把共享锁。有了这把锁之后，同一时刻，就只会有一个进程在accpet连接，这样就不会有惊群问题了。accept_mutex是一个可控选项，我们可以显示地关掉，默认是打开的。当一个worker进程在accept这个连接之后，就开始读取请求，解析请求，处理请求，产生数据后，再返回给客户端，最后才断开连接，这样一个完整的请求就是这样的了。我们可以看到，一个请求，完全由worker进程来处理，而且只在一个worker进程中处理。
来自：https://www.daimajiaoliu.com/daima/4ed14cdce900403#heading-9