
正文
php进程间共享数据 php进程通信
提示:扫一扫查出行【扫一扫了解最新限行尾号】
复制提示
php-fpm的工作机制
概括来说,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(),具体逻辑这里不再展开,比较容易理解。
原文出处:
相关问答
Q1: php处理字节流
字节流是由字节组成的,
字节流是最基本的,所有的InputStrem和OutputStream的子类都是,主要用在处理二进制数据,它是按字节来处理的
字符流和字节流都是什么
流就是stream. 一个连续的字节队列。
流是程序输入或输出的一个连续的字节序列,设备(例如鼠标,键盘,磁盘,屏幕和打印机)的输入和输出都是用流来处理的。在C语言中,所有的流均以文件的形式出现---不一定是物理磁盘文件,还可以是对应与某个输入/输出源的逻辑文件
流(streams)在I/O系统中是一种I/O机制和功能,或者称为streams子系统。它本身并不是一个物理设备的概念。
引入流的目的:
传统的字符设备驱动程序框架有许多缺点,这表现在:
。内核与字符设备驱动程序间接口的抽象层次太高
。内核没有为字符设备提供可靠的缓冲区分配和管理功能
。许多系统对字符设备的界面是把数据看成是FIFO(先进先出)的字节流,因此没有识别消息边界,区分普通设备和控制信息,以及判定不同消息优先级的能力,也没有字节流流量控制
。在网络数据传输设备中这些问题更突出。网络中数据传输是基于消息或数据分组的。
流的概念:
用通讯中的术语来说,流是全双工的处理过程,它是内核中驱动程序和用户进程之间的数据传输通道。
从流的构造上来说,它由一个流头,一个流驱动程序尾,以及其间的零个或若干个可选模块构成 。流头是一个用户级接口,它允许用户应用程序通过系统调用接口来访问流。驱动程序尾与底层设备通信。在流的中间的模块是处理数据的。
字节流与字符流主要的区别是他们的的处理对象
字节流是由字节组成的,字符流是由字符组成的. Java里字符由两个字节组成.
字节流是最基本的,所有的InputStrem和OutputStream的子类都是,主要用在处理二进制数据,它是按字节来处理的
但实际中很多的数据是文本,又提出了字符流的概念,它是按虚拟机的encode来处理,也就是要进行字符集的转化。在从字节流转化为字符流时,实际上就是byte[]转化为String时,
public String(byte bytes[], String charsetName)
有一个关键的参数字符集编码,通常我们都省略了,那系统就用操作系统默认的lang
流式传输主要指将整个音频和视频及三维媒体等多媒体文件经过特定的压缩方式解析成一个个压缩包,由视频服务器向用户计算机顺序或实时传送。在采用流式传输方式的系统中,用户不必像采用下载方式那样等到整个文件全部下载完毕,而是只需经过几秒或几十秒的启动延时即可在用户的计算机上利用解压设备对压缩的A/V、3D等多媒体文件解压后进行播放和观看。此时多媒体文件的剩余部分将在后台的服务器内继续下载。
Q2: 502 Bad Gateway 怎么解决
502 Bad Gateway是一种报错提示,这一错误并不意味着上游服务器已关闭(无响应网关/代理),而是上游服务器和网关/代理不同意的协议交换数据。
第一种原因:目前lnmp一键安装包比较多的问题就是502 Bad Gateway,大部分情况下原因是在安装php前,脚本中某些lib包可能没有安装上,造成php没有编译安装成功。解决办法:可以尝试根据lnmp一键安装包中的脚本手动安装一下,看看是什么错误导致的。
第二种原因:在php.ini里,eaccelerator配置项一定要放在Zend Optimizer配置之前,否则也可能引起502 Bad Gateway
第三种原因:在安装好使用过程中出现502问题,一般是因为默认php-cgi进程是5个,可能因为phpcgi进程不够用而造成502,需要修改/usr/local/php/etc/php-fpm.conf 将其中的max_children值适当增加。
第四种原因:php执行超时,修改/usr/local/php/etc/php.ini 将max_execution_time 改为300。
第五种原因:磁盘空间不足,如mysql日志占用大量空间。
第六种原因:查看php-cgi进程是否在运行。
另外的解决办法:
Nginx 502 Bad Gateway的含义是请求的PHP-CGI已经执行,但是由于某种原因(一般是读取资源的问题)没有执行完毕而导致PHP-CGI进程终止,一般来说Nginx 502 Bad Gateway和php-fpm.conf的设置有关。
php-fpm.conf有两个至关重要的参数,一个是max_children,另一个是request_terminate_timeout,但是这个值不是通用的,而是需要自己计算的。
在安装好使用过程中出现502问题,一般是因为默认php-cgi进程是5个,可能因为phpcgi进程不够用而造成502,需要修改/usr/local/php/etc/php-fpm.conf 将其中的max_children值适当增加。
计算的方式如下:如果服务器性能足够好,且宽带资源足够充足,PHP脚本没有系循环或BUG的话可以直接将 request_terminate_timeout设置成0s。0s的含义是让PHP-CGI一直执行下去而没有时间限制。如果做不到这一点,也就 是说PHP-CGI可能出现某个BUG,或者宽带不够充足或者其他的原因导致PHP-CGI假死那么就建议给 request_terminate_timeout赋一个值,这个值可以根据服务器的性能进行设定。一般来说性能越好可以设置越高,20分钟-30分 钟都可以。
而max_children这个值又是怎么计算出来的呢?这个值原则上是越大越好,php-cgi的进程多了就会处理的很快,排队的请求就会很少。 设置max_children也需要根据服务器的性能进行设定,一般来说一台服务器正常情况下每一个php-cgi所耗费的内存在20M左右。
按照官方的答案,排查了相关的可能,并结合了网友的答案,得出了下面的解决办法:
1、查看php fastcgi的进程数(max_children值)代码:netstat -anpo | grep “php-cgi” | wc -l
5(假如显示5)
2、查看当前进程,代码:top观察fastcgi进程数,假如使用的进程数等于或高于5个,说明需要增加(根据机器实际状况而定)
3、调整/usr/local/php/etc/php-fpm.conf 的相关设置
value name=”max_children”10/value
value name=”request_terminate_timeout”60s/value
max_children最多10个进程,按照每个进程20MB内存,最多200MB。
request_terminate_timeout执行的时间为60秒,也就是1分钟。
Q3: PHP进程管理三种模式
ondemand:按请示创建进程数;
dynamic:初始化启动number进程数;
static:固定启动进程数;
php-fpm进程管理一共有三种模式: ondemand、static、dynamic php进程间共享数据,我们可以在同一个fpm的master配置三种模式,看下图1。php-fpm的工作模式和nginx类似,都是一个master,多个worker模型。每个worker都在accept本pool内的监听套接字(linux已不存在惊群现象)。
ondemand
在php-fpm启动的时候,不会给这个pool启动任何一个worker,是按需启动,当有连接过来才会启动。
配置文件(我的配置文件地址为:/usr/local/php/etc/php-fpm.conf)
当前pool的名字为test
原理
ondemand原理图
1. 从上图可以看出,新建worker的触发条件是连接的到来,而不是实际的请求(例如,只进行连接比如telnet,不发请求数据也会新建worker)
2. worker的数量受限于pm.max_children配置,同时受限全局配置process.max(准确的说,三种模式都受限于全局配置)
3.1秒定时器作用
找到空闲worker,如果空闲时间超过pm.process_idle_timeout大小,关闭。这个机制可能会关闭所有的worker。
配置项要求
1. pm.max_children 0
2. pm.process_idle_timeout 0,如果不设置,默认10s
优缺点
优点:按流量需求创建,不浪费系统资源(在硬件如此便宜的时代,这个优点略显鸡肋)
缺点:由于php-fpm是短连接的,所以每次请求都会先建立连接,建立连接的过程必然会触发上图的执行步骤,所以,在大流量的系统上master进程会变得繁忙,占用系统cpu资源,不适合大流量环境的部署
dynamic
在php-fpm启动时,会初始启动一些worker,在运行过程中动态调整worker数量,worker的数量受限于pm.max_children配置,同时受限全局配置process.max
当前pool的名字为test
原理
dynamic原理图
1. 1秒定时器作用
检查空闲worker数量,按照一定策略动态调整worker数量,增加或减少。增加时,worker最大数量=max_children· =全局process.max;减少时,只有idle pm.max_spare_servers时才会关闭一个空闲worker。
idle pm.max_spare_servers,关闭启动时间最长的一个worker,结束本次处理
idle = pm.max_children,打印WARNING日志,结束本次处理
idle pm.max_children,计算一个num值,然后启动num个worker,结束本次处理
配置项要求
1. pm.min_spare_servers/pm.max_spare_servers有效范围(0,pm.max_children]
2. pm.max_children 0
3. pm.min_spare_servers=pm.max_spare_servers
4. pm.start_servers有效范围[pm.min_spare_servers,pm.max_spare_servers]如果没有配置,默认pm.min_spare_servers + (pm.max_spare_servers - pm.min_spare_servers) / 2
优缺点
优点:动态扩容,不浪费系统资源,master进程设置的1秒定时器对系统的影响忽略不计;
缺点:如果所有worker都在工作,新的请求到来只能等待master在1秒定时器内再新建一个worker,这时可能最长等待1s;
static
php-fpm启动采用固定大小数量的worker, 在运行期间也不会扩容,虽然也有1秒的定时器,仅限于统计一些状态信息,例如空闲worker个数,活动worker个数,网络连接队列长度等信息。
当前pool的名字为test
原理
配置项要求
1、pm.max_children 0 必须配置,且只有这一个参数生效
优缺点
如果配置成static,只需要考虑max_children的数量,数量取决于cpu的个数和应用的响应时间,我司配置的是50。
我司不考虑动态的增加减少那么十几个或者几十个worker,我们的内存没有紧张到这个程度,所以,我们一步到位,把worker数配置到支持最大流量,(哈哈,50也是随便定的,足矣足矣呢)
最后我们再介绍下worker的工作流程
fastcgi与php-fpm的关系一句话解读:fastcgi只是通信应用协议,php-fpm就是实现php进程间共享数据了fastcig协议,并嵌入php进程间共享数据了一个 PHP 解释器。
php进程间共享数据的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于php进程通信、php进程间共享数据的信息别忘了在本站进行查找喔。








