面试-PHP篇-PHP-FPM多进程模型

 

此篇为系列第一篇：PHP-FPM的多进程模型。那么，我们谈论PHP-FPM多进程模型的时候，作为PHPer的你，可能需要先看看下面一些关于PHP-FPM的多进程模型，是否都有所了解

①：PHP-FPM启动进程的方式主要有哪几种，区别是什么？
②：PHP-FPM，是主进程接收请求转给子进程，还是子进程单独接收请求并处理，如何验证？
③：为何在PHP-FPM模式下，PHP代码很少有人去做连接池？
④：PHP-FPM模式性能差的体现有哪些，如何优化？
⑤：PHP-FPM模式下的Yac为何无法和Cli模式无法共享内存？

1、PHP-FPM是多进程模式，master进程管理worker进程，进程的数量，都可以通过php-fpm.conf做具体配置，而PHP-FPM的进程，亦可以分为动态模式及静态模式。

①：静态（static）：直接开启指定数量的php-fpm进程，不再增加或者减少；启动固定数量的进程，占用内存高。但在用户请求波动大的时候，对Linux操作系统进程的处理上耗费的系统资源低。
②：动态（dynamic）：开始的时候开启一定数量的php-fpm进程，当请求量变大的时候，动态的增加php-fpm进程数到上限，当空闲的时候自动释放空闲的进程数到一个下限。动态模式，会根据max、min、idle children 配置，动态的调整进程数量。在用户请求较为波动，或者瞬间请求增高的时候，进行大量进程的创建、销毁等操作，而造成Linux负载波动升高，简单来说，请求量少，PHP-FPM进程数少，请求量大，进程数多。优势就是，当请求量小的时候，进程数少，内存占用也小。
③：按需模式（ondemand）：这种模式下，PHP-FPM的master不会fork任何的子进程，纯粹就是按需启动子进程，这种模式很少使用，因为这种模式，基本上是无法适应有一定量级的线上业务的。由于php-fpm是短连接的，所以每次请求都会先建立连接，建立连接的过程必然会触发上图的执行步骤，所以，在大流量的系统上master进程会变得繁忙，占用系统cpu资源，不适合大流量环境的部署。这种模式，贴一个简单的网络上的图来说明：

需要注意2个点，“连接”，及“数据”到来。有连接进来再fork进程，同样可以达到子进程继承父进程上下文，然后子进程处理用户请求这个目的。

具体的，关于动态、静态进程模式的相关参数，可参考PHP官方文档，我们需要关注的是，对于我们自身的业务，如何选择PHP-FPM的模式为动态还是静态。

比较大内存的服务器来说，设置为静态的话会提高效率。因为频繁开关php-fpm进程也会有时滞，所以内存够大的情况下开静态效果会更好。数量也可以根据 内存/30M 得到。比如说2GB内存的服务器，可以设置为50；4GB内存可以设置为100等。高配机器选静态，低配机器（省内存）选动态，高配机器用动态不能充分利用内存资源和CPU资源，也无法及时应对瞬时高并发，甚至可能短时间造成5xx错误。

2、PHP-FPM，是主进程接收请求转给子进程，还是子进程单独接收请求并处理，如何验证

PHP-FPM的进程管理方式和Nginx的进程管理方式类似，在处理用于请求上，并非是主进程接受请求后转给子进程，而是子进程抢占式的接受用户的请求，本质上，其实PHP-FPM的多进程，以及Nginx的多进程，其实都是主进程监听的同一个端口（被动套接字）后，fork子进程达到多个进程监听同一个端口的目的。 Linux系统，所有的进程IO操作，都需要和操作系统打交道，也就是说，所有IO操作，操作系统都知道，而这个过程，也就是我们常说的“系统调用”。我们可以从系统调用入手解决这个问题。 系统调用的查看，可以使用strace。

对于如何验证相对简单，有2种方式；其一，看php-fpm进程的日志，这需要配置好合适的php-fpm日志格式；其二，既然IO数据会通过内核态过度到用户态进程，那么，我们通过strace -p <pid>命令去跟踪系统调用即可。分别跟踪php-fpm的主进程id以及php-fpm子进程id，然后访问nginx，由nginx通过fast-cgi协议转到php-fpm进程上，看在哪个进程上发送了系统调用。

3、为何在PHP-FPM模式下，PHP代码很少有人去做连接池

首先，PHP-FPM模式下，注定一个请求的生命周期只有1次。也就是说，从FPM请求到请求，解析PHP脚本，FPM的Zend虚拟机分配资源执行，到最后的处理结束，PHP-FPM会回收这次请求的所有资源。

当然，PHP-FPM之所以这么做，①：目的是让开发不需要关心资源的回收的处理，所以可能你没怎么关心过网络的关闭、文件描述符的关闭等等。②：减少内存溢出的情况。

如果在这种模式下，你实现了连接池，也意味着请求结束，连接池消失，做了一次无用功而已。

“鸡肋的”pconnect。pconnect，持久化链接，也就是链接不释放。但问题在于，PHP-FPM是多进程模式，而持久化的链接，存在于进程中，也就意味着，如果一台机器有300个FPM进程，会一次性初始化300个持久化链接。 如果因为面临业务活动，冒然对机器扩容，很可能造成业务的数据库连接数直接打满。

4、PHP-FPM模式性能差的体现有哪些，如何优化

先思考为何性能差，一个应用的性能如果说差，往往会从2个方面来说，一个是IO性能，一个是计算性能。

IO上来说，PHP-FPM模式下，难以做连接池，所以高并发业务下，网络的处理会有劣势。 注意：我这里一直在说的，都是 PHP-FPM模式下，在CLI模式下，你还是可以做自己的连接池的，只不过这个连接池，仅限于CLI模式的单进程内，这个模式还不能用在处理网络请求（比如HTTP请求），因为PHP默认单进程模式，FPM、CLI都是默认单进程，即便CLI可以做连接池，也不方便做链接保活（不能同时做心跳检测）

计算性能上来说，其实PHP是C写的，单纯的论计算性能是不错的。 但问题在于，PHP在处理请求的时候，每次都要解析PHP脚本、翻译PHP代码为opcode、用Zend虚拟机执行opcode，处理结束，释放资源。因此算下来，也是PHP慢的最大原因之一。

如何优化：

①：对于计算性能来说，使用 Zend OPcache 扩展，缓存字节码。
②：对于IO性能来说，使用文件cache或者memcached减轻对网络Cache的压力；使用 Yac 减轻对 Cache层的压力；在同一次请求中；复用链接不要每次都用新的；合理设计日志组件类库，优化Logger减少对文件操作的次数来减少IO的压力。

关于设计一个合格的Logger组件，我们需要注意几个点：

①：每次请求，只做一次日志写操作，不要每次别人调用你的函数，你都去执行一次类似file_put_contents的操作。
②：兼容各种类似错误，换句话说，即使PHP fatal error了，你也得能把知名错误之前的日志记录下来。这个实现，可以借助PHP类的析构方法来做。也可以使用更好的 register_shutdown_function 来注册一个钩子，在PHP请求结束的时候，回调此钩子，完成做最后的日志操作。

5、PHP-FPM模式下的Yac为何无法和Cli模式无法共享内存

我们知道，PHP扩展开发中，首要执行的一个宏，便是 PHP_MINIT_FUNCTION，Yac扩展，需要在PHP-FPM进程启动的时候，便初始化一块共享内存，供各个进程来共享使用，因此，要能共享，关键就在于需要一个相同的标识，各个进程都知道才可以。Yac扩展的初始化流程为：

 

PHP_MINIT_FUNCTION->yac_storage_startup->yac_allocator_startup->create_segments

我们查看 create_segments 的具体实现：

 

static int create_segments(size_t requested_size, zend_shared_segment_posix ***shared_segments_p, int *shared_segments_count, char **error_in)
{
    zend_shared_segment_posix *shared_segment;
    char shared_segment_name[sizeof("/ZendAccelerator.") + 20];

    *shared_segments_count = 1;
    *shared_segments_p = (zend_shared_segment_posix **) calloc(1, sizeof(zend_shared_segment_posix) + sizeof(void *));
    if (!*shared_segments_p) {
        *error_in = "calloc";
        return ALLOC_FAILURE;
    }
    shared_segment = (zend_shared_segment_posix *)((char *)(*shared_segments_p) + sizeof(void *));
    (*shared_segments_p)[0] = shared_segment;

  // 这里打开共享内存块需要的Id，也就是 shared_segment_name
    sprintf(shared_segment_name, "/ZendAccelerator.%d", getpid());
    
    // 这里，打开一块共享内存
    shared_segment->shm_fd = shm_open(shared_segment_name, O_RDWR|O_CREAT|O_TRUNC, 0600);
    if (shared_segment->shm_fd == -1) {
        *error_in = "shm_open";
        return ALLOC_FAILURE;
    }

上面做了一些注释，最关键的是开启共享内存需要的系统ID，shared_segment_name，此值，包含了进程的ID。也就是php-fpm的主进程id。这就是，PHP-FPM模式所有进程间能够通信的奥秘所在（它们有相同的共享内存标识ID）。而，如果我们是想要通过PHP脚本，使用yac扩展读取这个共享内存，会这样做：

 

$yac = new Yac();
$key = "something"
$yac->get($key);

在CLI模式下，这样是不可能拿到PHP-FPM模式下设置的共享内存数据的因为，因为CLI模式下，执行php脚本，进程ID，和PHP-FPM模式下的进程ID，根本就不相同。

总结来说，在后边会讲到进程间通讯，会讲到基于共享内存的通讯。多进程要共享内存通信，必须要一开始就协调好一个唯一ID，这个ID，多个进程间都要知道，PHP-FPM是多进程，主进程fork子进程出来，子进程自然知道这个唯一ID是什么（因为Linux进程fork会把整个进程的堆栈内存都fork一遍）。 但是，php a.php 这样执行，其实是一个完全独立的进程，和php-fpm没任何关系，这样的进程，自然不能知道php-fpm进程里的那个唯一ID是什么。

 

 

 

Nginx+PHP-FPM运行原理

CGI

common gateway interface (公共网关接口)

请求模式:
    Web Brower(浏览器) ----(通过http协议传输)----> Http Server(服务器nginx/apache) -----> CGI Program -----> Db

Server 与 CGI 通过 STDIN/STDOUT(标准的输入/输出)进行数据传递
nginx(动态加载模块) apache(指定加载模块)

CGI工作原理

每当客户请求CGI的时候，WEB服务器就请求操作系统生成一个新的CGI解释器进程(如php-cgi.exe)，
CGI 的一个进程则处理完一个请求后退出，下一个请求来时再创建新进程。
当然，这样在访问量很少没有并发的情况也行。可是当访问量增大，并发存在，这种方式就不 适合了。于是就有了fastcgi。

FastCGI

像是一个常驻(long-live)型的CGI，它可以一直执行着，只要激活后，
不会每次都要花费时间去fork一次（这是CGI最为人诟病的fork-and-execute 模式）。

一般情况下，FastCGI的整个工作流程是这样的：
    1.Web Server启动时载入FastCGI进程管理器（IIS ISAPI或Apache Module)
    2.FastCGI进程管理器自身初始化，启动多个CGI解释器进程(可见多个php-cgi)并等待来自Web Server的连接。
    3.当客户端请求到达Web Server时，FastCGI进程管理器选择并连接到一个CGI解释器。 Web server将CGI环境变量和标准输入发送到FastCGI子进程php-cgi。
    4.FastCGI 子进程完成处理后将标准输出和错误信息从同一连接返回Web Server。
      当FastCGI子进程关闭连接时， 请求便告处理完成。
      FastCGI子进程接着等待并处理来自FastCGI进程管理器(运行在Web Server中)的下一个连接。 
      在CGI模式中，php-cgi在此便退出了。

php-fpm(PHP内置的一种fast-cgi)

php-fpm即php-Fastcgi Process Manager.
php-fpm是 FastCGI 的实现，并提供了进程管理的功能。
进程包含 master 进程和 worker 进程两种进程。
master 进程只有一个，负责监听端口，接收来自 Web Server 的请求，而 worker 进程则一般有多个(具体数量根据实际需要配置)，
每个进程内部都嵌入了一个 PHP 解释器，是 PHP 代码真正执行的地方。

请求步骤

Web Brower(浏览器访问) www.example.com
|
        |
   通过http协议传输  
|
        |
    http server
 (服务器nginx/apache)            
|
        |
     配置解析    
路由到 www.example.com/index.php
|
        |
加载 nginx 的 fast-cgi 模块
|
        |
fast-cgi 监听 127.0.0.1:9000 地址
通过 fast-cgi 协议将请求转发给 php-fpm 处理
|
        |
请求到达 127.0.0.1:9000
|
        |
php-fpm 监听 127.0.0.1:9000
可通过 php-fpm.conf 进行修改