PHP FPM源代码反刍品味之四:事件处理
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了PHP FPM源代码反刍品味之四:事件处理相关的知识,希望对你有一定的参考价值。
参考技术A FPM master 进程启动后,会进入函数fpm_event_loop,无限循环.
处理事件.
master 进程所做的的事,总的来说就是两类:
简称timer事件,需按时运行,主要有3个:
简称fd事件,需从文件句柄(file descriptor)读取到指令后,依指令运行.
重复一下,unix 下一切IO, 皆文件,socket ,socketpair,pipe 都返回文件句柄(fd) 用于通信.
主要的fd有:
对于timer事件,多个事件在事件轴上是依次排列的,只需反复检查,到时运行.
对于fd事件,需监听多个fd,需用到我们第二篇讲的IO多路复用技术.
如果满足事件条件,则处理事件内容.
FPM设计上,两类事件使用同一个结构,并且事件触发条件和事件处理逻辑放到同一个事件对象里(C语言对象就是结构体).
举个例子, 打铃下课,打铃是触发条件,下课是事件内容,两个同时放到一个事件对象 ,这是一个很好的设计.
fd值: -1
flags值: FPM_EV_PERSIST
which值: FPM_EV_TIMEOUT
fd值: 获取触发指令的文件fd
flags值: FPM_EV_EDGE(fd事件底层的边缘触发标志,需系统支持)
which值: FPM_EV_READ
两类事件分别放在两个事件队列
static struct fpm_event_queue_s *fpm_event_queue_timer = NULL;
static struct fpm_event_queue_s *fpm_event_queue_fd = NULL;
事件队列的结构很常见,双向队列:
typedef struct fpm_event_queue_s
struct fpm_event_queue_s *prev;
struct fpm_event_queue_s *next;
struct fpm_event_s *ev;
fpm_event_queue;
4移除事件 (fpm_event_del -> fpm_event_queue_del)
简单的出列操作:
static int fpm_event_queue_del(struct fpm_event_queue_s **queue, struct fpm_event_s *ev)
对于fd事件,需在底层事件轮询机制里移除(如:epoll)
5,运行事件回调函数:
6, 底层事件轮询模块结构
不同的操作系统,支持不同的IO事件机制,linux 支持epoll,
windows支持select, freebsd 支持kqueue,这个结构统一操作接口
在函数fpm_event_init_main里 调用module->init初始化
fpm 里对应的配置
master进程在fpm_event_loop函数里无限循环,处理定时任务和fd事件.
期间会在module->wait阻塞片刻,对于epoll机制,就是epoll_wait.
php-fpm的工作机制
参考技术A概括来说,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:
启动 fpm 后查看进程:
具体实现上 worker pool 通过fpm_worker_pool_s这个结构表示,多个 worker pool 组成一个单链表
接下来看下 fpm 的启动流程,从main()函数开始:
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():
这里会通过socketpair()创建一个管道,这个管道并不是用于 master 与 worker 进程通信的,它只在 master 进程中使用,具体用途在稍后介绍 event 事件处理时再作说明。另外设置 master 的信号处理 handler,当 master 收到 SIGTERM、SIGINT、SIGUSR1、SIGUSR2、SIGCHLD、SIGQUIT 这些信号时将调用sig_handler()处理:
(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 进程的。
在 fork 后 worker 进程返回了监听的套接字继续 main() 后面的处理,而 master 将永远阻塞在fpm_event_loop(),接下来分别介绍 master、worker 进程的后续操作。
fpm_run()执行后将 fork 出 worker 进程,worker 进程返回main()中继续向下执行,后面的流程就是 worker 进程不断 accept 请求,然后执行 PHP 脚本并返回。整体流程如下:
worker 进程一次请求的处理被划分为 5 个阶段:
worker 处理到各个阶段时将会把当前阶段更新到fpm_scoreboard_proc_s->request_stage,master 进程正是通过这个标识判断 worker 进程是否空闲的。
接下来我们来看下 master 是如何管理 worker 进程的,首先介绍下三种不同的进程管理方式:
前面介绍到在fpm_run()中 master 进程将进入fpm_event_loop():
这就是 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 注册的信号逐个看下不同用途:
具体处理逻辑在 fpm_got_signal() 函数中,这里不再罗列。
(2)fpm_pctl_perform_idle_server_maintenance_heartbeat():
这是进程管理实现的主要事件,master 启动了一个定时器,每隔 1s 触发一次,主要用于 dynamic、ondemand 模式下的 worker 管理,master 会定时检查各 worker pool 的 worker 进程数,通过此定时器实现 worker 数量的控制,处理逻辑如下:
(3)fpm_pctl_heartbeat():
这个事件是用于限制 worker 处理单个请求最大耗时的,php-fpm.conf 中有一个request_terminate_timeout的配置项,如果 worker 处理一个请求的总时长超过了这个值那么 master 将会向此 worker 进程发送kill -TERM信号杀掉 worker 进程,此配置单位为秒,默认值为 0 表示关闭此机制,另外 fpm 打印的 slow log 也是在这里完成的。
除了上面这几个事件外还有一个没有提到,那就是 ondemand 模式下 master 监听的新请求到达的事件,因为 ondemand 模式下 fpm 启动时是不会预创建 worker 的,有请求时才会生成子进程,所以请求到达时需要通知 master 进程,这个事件是在fpm_children_create_initial()时注册的,事件处理函数为fpm_pctl_on_socket_accept(),具体逻辑这里不再展开,比较容易理解。
原文出处: https://www.fanhaobai.com/2017/10/internal-php-fpm.html
以上是关于PHP FPM源代码反刍品味之四:事件处理的主要内容,如果未能解决你的问题,请参考以下文章
脚本 @php artisan package:discover 处理返回的 post-autoload-dump 事件,错误代码为 255
Voyager:“@php artisan package:discover --ansi 处理返回的 post-autoload-dump 事件,错误代码为 1”
脚本 php artisan 优化处理使用 laravel 5.4 返回的 post-update-cmd 事件,错误代码为 1