一切的起点都是因为看了某培训机构的免费公开课,重新学习了网络IO的一些事情，所以就想着结合着学的知识自己研究一下，包括在用的Nginx， PHP-FPM 等的东西。也算是对之前的知识重新梳理一下。从网上看了一下文章，结合自己的实战，发现下面的文章和自己的疑惑一样，下文正好解决了我的疑惑，所以就记录一下。
下文链接
同事发了一篇文档:Nginx 与 FPM 的工作机制，里面提及FPM 的 master 进程接收到请求，然后master 进程根据配置指派特定的 worker进程进行请求处理，如果没有可用进程，返回错误，这也是我们配合 Nginx 使用时遇到502错误比较多的原因。
我曾经认为Nginx也是由master负责派发请求给worker，但同事那边马上发了篇文档:nginx平台初探出来打脸，文章提到master只负责管理worker，如重启，重新加载配置文件，并不会派发请求。
为什么我会纠结呢？ fpm一开始其实是一个第三方管理软件，类似spawn-cgi，说白了就是负责启动php-cgi进程的，那PHP官方把它整合进来作为官方的php-cgi管理工具后，会委以「派发请求」这样的重任吗？
早上和同事一起纠结了一下，纠结过程如下：
strace对比master和worker的行为，同事把Nginx和fpm都设置成了1个worker进程观察，得出结论是不会经过fpm的master进程
strace -e network -p fpm_master_pid
strace -e network -p fpm_worker_pid
下面是我自己操作的时候用到的命令
strace -ff -o oo fpm-master-pid
strace -ff -o oo fpm-worker-pid
下图是抓到的fpm master进程的一些系统调用
下图是抓到的fpm worker进程的一些系统调用 
跟这个文章里的说法是一样的：关于fastcgi和php-fpm的疑惑，引用如下
master进程并不接收和分发请求,而是worker进程直接accpet请求后poll处理. master进程不断调用epoll_wait和getsockopt是用来异步处理信号事件和定时器事件.
这里提一下,Nginx也类似,master进程并不处理请求,而是worker进程直接处理, 不过区别在于Nginx的worker进程是epoll异步处理请求,而PHP-FPM仍然是poll.
把master干掉，看请求是否可以正常处理，经实际测试，master干掉后，worker依然在，请求也可以正常处理。
kill -HUP fpm_master_pid
其他
worker进程数量不够的时候，显然是manager启动了更多进程，这个时候是manager怎么知道的
答：PHP源码分析 – PHP-FPM运行模式详解，看起来就是满足下面的条件就会执行 fpm_children_make
1. idle < pm_min_spare_servers
2. running_children < pm_max_children
3. MIN(MIN(idle_spawn_rate, pm_min_spare_servers - idle), pm_max_children - running_children) > 0
nginx中配置的fastcgi_pass默认是fastcgi的监听端口，这个配置的意义是什么？
答：浅谈多进程程序的进程控制和管理方式，主要看「多进程下的套接字」，这段文字解释了为什么多进程不需要派发，因为它socket是多进程共享的
纠结论
fpm的master并不承担派发请求的角色。
其他资料
NGINX 1.9.1 新特性：套接字端口共享
python使用master worker管理模型开发服务端，里面提到各种进程信号