php心跳

A. php可不可以socket通信长连接，不断开，然后实现多次通讯

当然可以，我都已经做过udp socket云端门禁管理系统，服务器socket监控设备连接状态，设备通过发送心跳包来维持连接，从而实现长连接，更多详情http://www.100txy.com/article/54.html

B. PHP用心跳机制计算用户页面的停留时长，没接触过，有谁能给个源码案例，或者给个好的思路也行

先用javascript的秒表功能一直计时，然后每次更新后的时间都存入本地的数据库，也就是local.Storage
做一个setTimeout 用来每20分钟alert，
然后 当 刷新页面的时候，就会检查local.storage里面有没有值，如果有的话
就从当前的值开始计时，就达到了继续计时的效果

C. 服务器怎么判断心跳包

设置个心跳时间，超过1分钟仍然没有更新的，就让脚本跑成离线就可以了
脚本自动执行，1分钟一次
操作一次，就触发一次数据库记录，插入数据库，然后判断数据库该字段是否有值

D. php-fpm master worker 关系介绍

## 1.3 FPM

php7-internal/fpm.md at master · pangudashu/php7-internal · GitHub

1.3 FPM

1.3.1 概述

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

root271550.00.11447042720?        Ss15:160:00php-fpm: masterprocess(/usr/local/php7/etc/php-fpm.conf)nobody  27156  0.0  0.1 144676  2416 ?        S    15:16  0:00 php-fpm: pool web1nobody  27157  0.0  0.1 144676  2416 ?        S    15:16  0:00 php-fpm: pool web1nobody  27159  0.0  0.1 144680  2376 ?        S    15:16  0:00 php-fpm: pool web2nobody  27160  0.0  0.1 144680  2376 ?        S    15:16  0:00 php-fpm: pool web2

具体实现上worker pool通过fpm_worker_pool_s这个结构表示，多个worker pool组成一个单链表：

structfpm_worker_pool_s {structfpm_worker_pool_s *next;//指向下一个worker poolstructfpm_worker_pool_config_s *config;//conf配置:pm、max_children、start_servers...intlistening_socket;//监听的套接字...//以下这个值用于master定时检查、记录worker数structfpm_child_s *children;//当前pool的worker链表intrunning_children;//当前pool的worker运行总数intidle_spawn_rate;intwarn_max_children;structfpm_scoreboard_s *scoreboard;//记录worker的运行信息，比如空闲、忙碌worker数...}

1.3.3 FPM的初始化

接下来看下fpm的启动流程，从main()函数开始：

//sapi/fpm/fpm/fpm_main.cintmain(intargc,char*argv[]){    ...//注册SAPI:将全局变量sapi_mole设置为cgi_sapi_molesapi_startup(&cgi_sapi_mole);    ...//执行php_mole_starup()if(cgi_sapi_mole.startup(&cgi_sapi_mole) == FAILURE) {returnFPM_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():

staticintsp[2];intfpm_signals_init_main(){structsigactionact;//创建一个全双工管道if(0>socketpair(AF_UNIX, SOCK_STREAM,0, sp)) {return-1;    }//注册信号处理handleract.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;    }return0;}

这里会通过socketpair()创建一个管道，这个管道并不是用于master与worker进程通信的，它只在master进程中使用，具体用途在稍后介绍event事件处理时再作说明。另外设置master的信号处理handler，当master收到SIGTERM、SIGINT、SIGUSR1、SIGUSR2、SIGCHLD、SIGQUIT这些信号时将调用sig_handler()处理：

staticvoidsig_handler(intsigno){staticconstcharsig_chars[NSIG +1] = {        [SIGTERM] ='T',        [SIGINT]  ='I',        [SIGUSR1] ='1',        [SIGUSR2] ='2',        [SIGQUIT] ='Q',        [SIGCHLD] ='C'};chars;    ...    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进程的。

intfpm_run(int*max_requests){structfpm_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) {gotorun_child;        }    }//master进程将进入event循环，不再往下走fpm_event_loop(0);run_child://只有worker进程会到这里*max_requests = fpm_globals.max_requests;returnfpm_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)等待下一个请求。

intmain(intargc,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_mole_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()：

voidfpm_event_loop(interr){//创建一个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 = mole->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进程因为异常原因(比如coremp了)退出而非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数量的控制，处理逻辑如下：

staticvoidfpm_pctl_perform_idle_server_maintenance(structtimeval*now){for(wp = fpm_worker_all_pools; wp; wp = wp->next) {structfpm_child_s *last_idle_child =NULL;//空闲时间最久的workerintidle =0;//空闲worker数intactive =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则杀掉该workerlast_idle_child->idle_kill=1;fpm_pctl_kill(last_idle_child->pid, FPM_PCTL_QUIT);            }continue;        }//dynamicif(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也是在这里完成的。

staticvoidfpm_pctl_check_request_timeout(structtimeval*now){structfpm_worker_pool_s *wp;for(wp = fpm_worker_all_pools; wp; wp = wp->next) {intterminate_timeout = wp->config->request_terminate_timeout;intslowlog_timeout = wp->config->request_slowlog_timeout;structfpm_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的实现还是比较简单的。

E. php workman心跳客户端关闭，服务端心跳代码不执行

怎么会不执行呢？
心跳的机制就是检测链接状态的。客户端关闭链接之后，正常workman 是可以监听到 客户断开了 ，如果出现网络原因。监听不到，就需要心跳包进行校检。workman 官方的心跳实例就是 检测客户端每个链接最后收发的时间。用定时器定期执行。如果在链接最后的时间超过规定的时间，就在总链接里面关闭掉这个链接。这样也就是 需要客户端定期发送一个心跳包。
js 的话用setinterval 周期一定要小于 服务端的心跳检测的周期。至于发送的数据随你自己的喜好了

F. php利用session怎么判断用户已离线

方法有好多种，但应该都跟心跳请求类似。
首先用户打开一个页面后，页面里面会有段js脚本来反复请求一个地址，即判断用户是否在线的地址（跟新浪微博隔一段时间请求一个地址查看是否有新消息类似）
比如判断页面为A，打开的页面为B ，则B 内的js脚本以ajax请求的方式每隔1分钟来访问A，A可以记录下最后一次的请求时间，然后你就可以拿这个最后一次请求的时间来判断用户是否离线，比如B每隔1分钟发送一次请求，如果最后活动时间与当前时间相差两分钟，就可以认为用户已离线。

还有一种方法，就是利用js的onunload事件
当用户关闭浏览器的时候，可以用onunload发送一个请求，注销掉session，或者将用户状态置为离线，都可以，不过没有上面靠谱就是，因为F5刷新页面也同样触onunload事件

方法还有很多，结合你需要实现的功能和业务，多想想就出来了