php-fpm是master（主）/worker（子）多进程架构，有点类似于nginx的设计风格。master进程主要负责CGI和PHP环境初始化、事件监听、子进程状态等，worker进程负责处理PHP请求。主人只负责管理。并不是很多人认为client发送的请求都分配给了worker进程。相反，工作进程负责监视和处理客户端的请求。master只负责管理worker，比如重启和重新加载配置。文件，请求将不会被发送。一旦工作进程被杀死，一个新的工作进程将被重新启动。所以客户端请求肯定会和响应一起处理。这进一步验证了上述结论。主进程负责监视子进程的状态。子进程挂掉后，会发信号给master进程，然后master进程重新启动一个新的worker进程。worker被同步阻塞。在处理其他请求之前，它必须等待此处理完成。并发性能不好。nginx和php-fpm的结合，完整的流程是这样的。www.example.com||Nginx||路由到www.example.com/index.php||加载nginx的fast-cgi模块||fast-cgi监听127.0.0.1:9000地址||www.example.com/index.php请求到达127.0.0.1:9000||php-fpm监听127.0.0.1:9000||php-fpm接收请求并启动工作进程处理请求||php-fpm处理请求并返回给nginx||nginx通过http返回结果给浏览器一、传统php-fpm工作模式存在的问题1、fastcgi进程管理器实现了fastcgi协议2、同步阻塞IO进程模型3、请求结束后释放所有资源和内存4.并发受限由于进程数5.PHP框架初始化占用大量计算资源2.php-fpm工作模式问题1.nginx基于epoll事件模型，一个worker可以处理多个请求同时2、fpm-worker可以同时处理一个请求3、master进程只负责处理worker进程监控、日志等4、client请求由elb解析，然后由nginx解析。5.fpm-worker每次处理请求前需要重新初始化mvc框架，然后释放资源6.高并发请求时，fpm-worker不够用，nginx直接响应5027，fpm-worker进程切换消耗很大（比如一个线上业务在4核8G内存的服务器上实际可以使用16个进程）
