當前位置:首頁 » 編程語言 » php心跳

php心跳

發布時間: 2022-11-30 05:58:52

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事件

方法還有很多,結合你需要實現的功能和業務,多想想就出來了

熱點內容
玩戰地5配置不行怎麼辦 發布:2024-03-29 22:10:28 瀏覽:981
javaice 發布:2024-03-29 21:56:37 瀏覽:355
編譯圖書 發布:2024-03-29 21:56:36 瀏覽:332
linux全選vi 發布:2024-03-29 21:55:11 瀏覽:774
艾譜保險箱初始密碼一般是什麼 發布:2024-03-29 21:48:11 瀏覽:825
商家粉腳本 發布:2024-03-29 21:34:57 瀏覽:151
我的世界ec伺服器怎麼獲得 發布:2024-03-29 21:21:44 瀏覽:709
小米4設置限制的訪問 發布:2024-03-29 21:21:10 瀏覽:406
linux向伺服器上傳文件 發布:2024-03-29 21:17:20 瀏覽:929
腳本健康cpu佔用率報警 發布:2024-03-29 21:16:42 瀏覽:255