FPM(FastCGI Process Manager)是PHP FastCGI运行模式的一个进程管理器，从它的定义可以看出，FPM的核心功能是进程管理，那么它用来管理什么进程呢？这个问题就须要从FastCGI提及了。
FastCGI是Web做事器(如：Nginx、Apache)和处理程序之间的一种通信协议，它是与Http类似的一种运用层通信协议，把稳：它只是一种协议！
前面曾几次再三强调，PHP只是一个脚本解析器，你可以把它理解为一个普通的函数，输入是PHP脚本。输出是实行结果，如果我们想用PHP代替shell，在命令行中实行一个文件，那么就可以写一个程序来嵌入PHP解析器，这便是cli模式，这种模式下PHP便是普通的一个命令工具。接着我们又想：能不能让PHP处理http要求呢？这时就涉及到了网络处理，PHP须要吸收要求、解析协议，然后处理完成返回要求。在网络运用处景下，PHP并没有像Golang那样实现http网络库，而是实现了FastCGI协议，然后与web做事器合营实现了http的处理，web做事器来处理http要求，然后将解析的结果再通过FastCGI协议转发给处理程序，处理程序处理完成后将结果返回给web做事器，web做事器再返回给用户，如下图所示。
PHP实现了FastCGI协议的解析，但是并没有详细实现网络处理，一样平常的处理模型：多进程、多线程，多进程模型常日是主进程只卖力管理子进程，而基本的网络事宜由各个子进程处理，nginx、fpm便是这种模式；另一种多线程模型与多进程类似，只是它是线程粒度，常日会由主线程监听、吸收要求，然后交由子线程处理，memcached便是这种模式，有的也是采取多进程那种模式：主线程只卖力管理子线程不处理网络事宜，各个子线程监听、吸收、处理要求，memcached利用udp协议时采取的是这种模式。
1.3.2 基本实现
概括来说，fpm的实现便是创建一个master进程，在master进程中创建并监听socket，然后fork出多个子进程，这些子进程各自accept要求，子进程的处理非常大略，它在启动后壅塞在accept上，有要求到达后开始读取要求数据，读取完成后开始处理然后再返回，在这期间是不会吸收其它要求的，也便是说fpm的子进程同时只能相应一个要求，只有把这个要求处理完成后才会accept下一个要求，这一点与nginx的事宜驱动有很大的差异，nginx的子进程通过epoll管理套接字，如果一个要求数据还未发送完成则会处理下一个要求，即一个进程会同时连接多个要求，它是非壅塞的模型，只处理生动的套接字。
fpm的master进程与worker进程之间不会直接进行通信，master通过共享内存获取worker进程的信息，比如worker进程当前状态、已处理要求数等，当master进程要杀掉一个worker进程时则通过发送旗子暗记的办法关照worker进程。
fpm可以同时监听多个端口，每个端口对应一个worker pool，而每个pool下对应多个worker进程，类似nginx中server观点。
在php-fpm.conf中通过[pool name]声明一个worker pool：
[web1]
listen = 127.0.0.1:9000
...
[web2]
listen = 127.0.0.1:9001
...
启动fpm后查看进程：ps -aux|grep fpm
root 27155 0.0 0.1 144704 2720 ? Ss 15:16 0:00 php-fpm: master process (/usr/local/php7/etc/php-fpm.conf)
nobody 27156 0.0 0.1 144676 2416 ? S 15:16 0:00 php-fpm: pool web1
nobody 27157 0.0 0.1 144676 2416 ? S 15:16 0:00 php-fpm: pool web1
nobody 27159 0.0 0.1 144680 2376 ? S 15:16 0:00 php-fpm: pool web2
nobody 27160 0.0 0.1 144680 2376 ? S 15:16 0:00 php-fpm: pool web2
详细实现上worker pool通过fpm_worker_pool_s这个构造表示，多个worker pool组成一个单链表：
struct fpm_worker_pool_s {
struct fpm_worker_pool_s next; //指向下一个worker pool
struct fpm_worker_pool_config_s config; //conf配置:pm、max_children、start_servers...
int listening_socket; //监听的套接字
...
//以下这个值用于master定时检讨、记录worker数
struct fpm_child_s children; //当前pool的worker链表
int running_children; //当前pool的worker运行总数
int idle_spawn_rate;
int warn_max_children;
struct fpm_scoreboard_s scoreboard; //记录worker的运行信息，比如空闲、劳碌worker数
...
}
1.3.3 FPM的初始化
接下来看下fpm的启动流程，从main()函数开始：
//sapi/fpm/fpm/fpm_main.c
int main(int argc, char argv[])
{
...
//注册SAPI:将全局变量sapi_module设置为cgi_sapi_module
sapi_startup(&cgi_sapi_module);
...
//实行php_module_starup()
if (cgi_sapi_module.startup(&cgi_sapi_module) == FAILURE) {
return FPM_EXIT_SOFTWARE;
}
...
//初始化
if(0 > fpm_init(...)){
...
}
...
fpm_is_running = 1;
fcgi_fd = fpm_run(&max_requests);//后面都是worker进程的操作，master进程不会走到下面
parent = 0;
...
}
fpm_init()紧张有以下几个关键操作：
(1)fpm_conf_init_main():
解析php-fpm.conf配置文件，分配worker pool内存构造并保存到全局变量中：fpm_worker_all_pools，各worker pool配置解析到fpm_worker_pool_s->config中。
(2)fpm_scoreboard_init_main(): 分配用于记录worker进程运行信息的共享内存，按照worker pool的最大worker进程数分配，每个worker pool分配一个fpm_scoreboard_s构造，pool下对应的每个worker进程分配一个fpm_scoreboard_proc_s构造，各构造的对应关系如下图。
(3)fpm_signals_init_main():
static int sp[2];
int fpm_signals_init_main()
{
struct sigaction act;
//创建一个全双工管道
if (0 > socketpair(AF_UNIX, SOCK_STREAM, 0, sp)) {
return -1;
}
//注册旗子暗记处理handler
act.sa_handler = sig_handler;
sigfillset(&act.sa_mask);
if (0 > sigaction(SIGTERM, &act, 0) ||
0 > sigaction(SIGINT, &act, 0) ||
0 > sigaction(SIGUSR1, &act, 0) ||
0 > sigaction(SIGUSR2, &act, 0) ||
0 > sigaction(SIGCHLD, &act, 0) ||
0 > sigaction(SIGQUIT, &act, 0)) {
return -1;
}
return 0;
}
这里会通过socketpair()创建一个管道，这个管道并不是用于master与worker进程通信的，它只在master进程中利用，详细用场在稍后先容event事宜处理时再作解释。其余设置master的旗子暗记处理handler，当master收到SIGTERM、SIGINT、SIGUSR1、SIGUSR2、SIGCHLD、SIGQUIT这些旗子暗记时将调用sig_handler()处理：
static void sig_handler(int signo)
{
static const char sig_chars[NSIG + 1] = {
[SIGTERM] = 'T',
[SIGINT] = 'I',
[SIGUSR1] = '1',
[SIGUSR2] = '2',
[SIGQUIT] = 'Q',
[SIGCHLD] = 'C'
};
char s;
...
s = sig_chars[signo];
//将旗子暗记关照写入管道sp[1]端
write(sp[1], &s, sizeof(s));
...
}
(4)fpm_sockets_init_main()
创建每个worker pool的socket套接字。
(5)fpm_event_init_main():
启动master的事宜管理，fpm实现了一个事宜管理器用于管理IO、定时事宜，个中IO事宜通过kqueue、epoll、poll、select等管理，定时事宜便是定时器，一定韶光后触发某个事宜。
在fpm_init()初始化完成后接下来便是最关键的fpm_run()操作了，此环节将fork子进程，启动进程管理器，其余master进程将不会再返回，只有各worker进程会返回，也便是说fpm_run()之后的操作均是worker进程的。
int fpm_run(int max_requests)
{
struct fpm_worker_pool_s wp;
for (wp = fpm_worker_all_pools; wp; wp = wp->next) {
//调用fpm_children_make() fork子进程
is_parent = fpm_children_create_initial(wp);
if (!is_parent) {
goto run_child;
}
}
//master进程将进入event循环，不再往下走
fpm_event_loop(0);
run_child: //只有worker进程会到这里
max_requests = fpm_globals.max_requests;
return fpm_globals.listening_socket; //返回监听的套接字
}
在fork后worker进程返回了监听的套接字连续main()后面的处理，而master将永久壅塞在fpm_event_loop()，接下来分别先容master、worker进程的后续操作。
1.3.4 要求处理
fpm_run()实行后将fork出worker进程，worker进程返回main()中连续向下实行，后面的流程便是worker进程不断accept要求，然后实行PHP脚本并返回。整体流程如下：
(1)等待要求： worker进程壅塞在fcgi_accept_request()等待要求；
(2)解析要求： fastcgi要求到达后被worker吸收，然后开始吸收并解析要求数据，直到request数据完备到达；
(3)要求初始化： 实行php_request_startup()，此阶段会调用每个扩展的：PHP_RINIT_FUNCTION()；
(4)编译、实行： 由php_execute_script()完成PHP脚本的编译、实行；
(5)关闭要求： 要求完成后实行php_request_shutdown()，此阶段会调用每个扩展的：PHP_RSHUTDOWN_FUNCTION()，然后进入步骤(1)等待下一个要求。
int main(int argc, char argv[])
{
...
fcgi_fd = fpm_run(&max_requests);
parent = 0;
//初始化fastcgi要求
request = fpm_init_request(fcgi_fd);
//worker进程将壅塞在这，等待要求
while (EXPECTED(fcgi_accept_request(request) >= 0)) {
SG(server_context) = (void ) request;
init_request_info();
//要求开始
if (UNEXPECTED(php_request_startup() == FAILURE)) {
...
}
...
fpm_request_executing();
//编译、实行PHP脚本
php_execute_script(&file_handle);
...
//要求结束
php_request_shutdown((void ) 0);
...
}
...
//worker进程退出
php_module_shutdown();
...
}
worker进程一次要求的处理被划分为5个阶段：
FPM_REQUEST_ACCEPTING: 等待要求阶段
FPM_REQUEST_READING_HEADERS: 读取fastcgi要求header阶段
FPM_REQUEST_INFO: 获取要求信息阶段，此阶段是将要求的method、query stirng、request uri等信息保存到各worker进程的fpm_scoreboard_proc_s构造中，此操作须要加锁，由于master进程也会操作此构造
FPM_REQUEST_EXECUTING: 实行要求阶段
FPM_REQUEST_END: 没有利用
FPM_REQUEST_FINISHED: 要求处理完成
worker处理到各个阶段时将会把当前阶段更新到fpm_scoreboard_proc_s->request_stage，master进程正是通过这个标识判断worker进程是否空闲的。
1.3.5 进程管理
这一节我们来看下master是如何管理worker进程的，首先先容下三种不同的进程管理办法：
static: 这种办法比较大略，在启动时master按照pm.max_children配置fork出相应数量的worker进程，即worker进程数是固定不变的
dynamic: 动态进程管理，首先在fpm启动时按照pm.start_servers初始化一定数量的worker，运行期间如果master创造空闲worker数低于pm.min_spare_servers配置数(表示要求比较多，worker处理不过来了)则会fork worker进程，但总的worker数不能超过pm.max_children，如果master创造空闲worker数超过了pm.max_spare_servers(表示闲着的worker太多了)则会杀掉一些worker，避免占用过多资源，master通过这4个值来掌握worker数
ondemand: 这种办法一样平常很少用，在启动时不分配worker进程，等到有要求了后再关照master进程fork worker进程，总的worker数不超过pm.max_children，处理完成后worker进程不会立即退出，当空闲韶光超过pm.process_idle_timeout后再退出
前面先容到在fpm_run()master进程将进入fpm_event_loop()：
void fpm_event_loop(int err)
{
//创建一个io read的监听事宜，这里监听的便是在fpm_init()阶段中通过socketpair()创建管道sp[0]
//当sp[0]可读时将回调fpm_got_signal()
fpm_event_set(&signal_fd_event, fpm_signals_get_fd(), FPM_EV_READ, &fpm_got_signal, NULL);
fpm_event_add(&signal_fd_event, 0);
//如果在php-fpm.conf配置了request_terminate_timeout则启动心跳检讨
if (fpm_globals.heartbeat > 0) {
fpm_pctl_heartbeat(NULL, 0, NULL);
}
//定时触发进程管理
fpm_pctl_perform_idle_server_maintenance_heartbeat(NULL, 0, NULL);
//进入事宜循环，master进程将壅塞在此
while (1) {
...
//等待IO事宜
ret = module->wait(fpm_event_queue_fd, timeout);
...
//检讨定时器事宜
...
}
}
这便是master整体的处理，其进程管理紧张依赖注册的几个事宜，接下来我们详细剖析下这几个事宜的功能。
(1)sp[1]管道可读事宜：
在fpm_init()阶段master曾创建了一个全双工的管道：sp，然后在这里创建了一个sp[0]可读的事宜，当sp[0]可读时将交由fpm_got_signal()处理，向sp[1]写数据时sp[0]才会可读，那么什么机遇会向sp[1]写数据呢？前面已经提到了：当master收到注册的那几种旗子暗记时会写入sp[1]端，这个时候将触发sp[0]可读事宜。
这个事宜是master用于处理旗子暗记的，我们根据master注册的旗子暗记逐个看下不同用场：
SIGINT/SIGTERM/SIGQUIT: 退出fpm，在master收到退出旗子暗记后将向所有的worker进程发送退出旗子暗记，然后master退出
SIGUSR1: 重新加载日志文件，生产环境中常日会对日志进行切割，切割后会天生一个新的日志文件，如果fpm不重新加载将无法连续写入日志，这个时候就须要向master发送一个USR1的旗子暗记
SIGUSR2: 重启fpm，首先master也是会向所有的worker进程发送退出旗子暗记，然后master会调用execvp()重新启动fpm，末了旧的master退出
SIGCHLD: 这个旗子暗记是子进程退出时操作系统发送给父进程的，子进程退出时，内核将子进程置为僵尸状态，这个进程称为僵尸进程，它只保留最小的一些内核数据构造，以便父进程查询子进程的退出状态，只有当父进程调用wait或者waitpid函数查询子进程退出状态后子进程才告终止，fpm中当worker进程由于非常缘故原由(比如coredump了)退出而非master主动杀掉时master将受到此旗子暗记，这个时候父进程将调用waitpid()查下子进程的退出，然后检讨下是不是须要重新fork新的worker
详细处理逻辑在fpm_got_signal()函数中，这里不再罗列。
(2)fpm_pctl_perform_idle_server_maintenance_heartbeat():
这是进程管理实现的紧张事宜，master启动了一个定时器，每隔1s触发一次，紧张用于dynamic、ondemand模式下的worker管理，master会定时检讨各worker pool的worker进程数，通过此定时器实现worker数量的掌握，处理逻辑如下：
static void fpm_pctl_perform_idle_server_maintenance(struct timeval now)
{
for (wp = fpm_worker_all_pools; wp; wp = wp->next) {
struct fpm_child_s last_idle_child = NULL; //空闲韶光最久的worker
int idle = 0; //空闲worker数
int active = 0; //劳碌worker数
for (child = wp->children; child; child = child->next) {
//根据worker进程的fpm_scoreboard_proc_s->request_stage判断
if (fpm_request_is_idle(child)) {
//找空闲韶光最久的worker
...
idle++;
}else{
active++;
}
}
...
//ondemand模式
if (wp->config->pm == PM_STYLE_ONDEMAND) {
if (!last_idle_child) continue;
fpm_request_last_activity(last_idle_child, &last);
fpm_clock_get(&now);
if (last.tv_sec < now.tv_sec - wp->config->pm_process_idle_timeout) {
//如果空闲韶光最长的worker空闲韶光超过了process_idle_timeout则杀掉该worker
last_idle_child->idle_kill = 1;
fpm_pctl_kill(last_idle_child->pid, FPM_PCTL_QUIT);
}
continue;
}
//dynamic
if (wp->config->pm != PM_STYLE_DYNAMIC) continue;
if (idle > wp->config->pm_max_spare_servers && last_idle_child) {
//空闲worker太多了，杀掉
last_idle_child->idle_kill = 1;
fpm_pctl_kill(last_idle_child->pid, FPM_PCTL_QUIT);
wp->idle_spawn_rate = 1;
continue;
}
if (idle < wp->config->pm_min_spare_servers) {
//空闲worker太少了，如果总worker数未达到max数则fork
...
}
}
}
(3)fpm_pctl_heartbeat():
这个事宜是用于限定worker处理单个要求最大耗时的，php-fpm.conf中有一个request_terminate_timeout的配置项，如果worker处理一个要求的总时长超过了这个值那么master将会向此worker进程发送kill -TERM旗子暗记杀掉worker进程，此配置单位为秒，默认值为0表示关闭此机制，其余fpm打印的slow log也是在这里完成的。
static void fpm_pctl_check_request_timeout(struct timeval now)
{
struct fpm_worker_pool_s wp;
for (wp = fpm_worker_all_pools; wp; wp = wp->next) {
int terminate_timeout = wp->config->request_terminate_timeout;
int slowlog_timeout = wp->config->request_slowlog_timeout;
struct fpm_child_s child;
if (terminate_timeout || slowlog_timeout) {
for (child = wp->children; child; child = child->next) {
//检讨当前当前worker处理的要求是否超时
fpm_request_check_timed_out(child, now, terminate_timeout, slowlog_timeout);
}
}
}
}
除了上面这几个事宜外还有一个没有提到，那便是ondemand模式下master监听的新要求到达的事宜，由于ondemand模式下fpm启动时是不会预创建worker的，有要求时才会天生子进程，以是要求到达时须要关照master进程，这个事宜是在fpm_children_create_initial()时注册的，事宜处理函数为fpm_pctl_on_socket_accept()，详细逻辑这里不再展开，比较随意马虎理解。
到目前为止我们已经把fpm的核心实现先容完了，事实上fpm的实现还是比较大略的。
以上便是Fpm启动机制及流程的详细剖析（附代码）的详细内容，更多请关注其它干系文章！
更多技巧请《转发 + 关注》哦！
