當前位置:首頁 > PHP教程 > php應用 > 列表

Fpm啟動機制及流程的詳細分析(附代碼)

發布:smiling 來源: PHP粉絲網  添加日期:2020-01-15 17:10:14 瀏覽: 評論:0 

本篇文章給大家帶來的內容是關于Fpm啟動機制及流程的詳細分析(附代碼),有一定的參考價值,有需要的朋友可以參考一下,希望對你有所幫助。

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:

  1. [web1] 
  2. listen = 127.0.0.1:9000 
  3. ... 
  4.  
  5. [web2] 
  6. listen = 127.0.0.1:9001 
  7. ... 

啟動fpm后查看進程:ps -aux|grep fpm

  1. root 27155 0.0 0.1 144704 2720 ? Ss 15:16 0:00 php-fpm: master process (/usr/local/php7/etc/php-fpm.conf) 
  2. nobody 27156 0.0 0.1 144676 2416 ? S 15:16 0:00 php-fpm: pool web1 
  3. nobody 27157 0.0 0.1 144676 2416 ? S 15:16 0:00 php-fpm: pool web1 
  4. nobody 27159 0.0 0.1 144680 2376 ? S 15:16 0:00 php-fpm: pool web2 
  5. 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組成一個單鏈表:

  1. struct fpm_worker_pool_s { 
  2.  
  3. struct fpm_worker_pool_s next; //指向下一個worker pool 
  4.  
  5. struct fpm_worker_pool_config_s config; //conf配置:pm、max_children、start_servers... 
  6.  
  7. int listening_socket; //監聽的套接字 
  8.  
  9. ... 
  10.  
  11. //以下這個值用于master定時檢查、記錄worker數 
  12.  
  13. struct fpm_child_s *children; //當前pool的worker鏈表 
  14.  
  15. int running_children; //當前pool的worker運行總數 
  16.  
  17. int idle_spawn_rate; 
  18.  
  19. int warn_max_children; 
  20.  
  21.  
  22.  
  23. struct fpm_scoreboard_s *scoreboard; //記錄worker的運行信息,比如空閑、忙碌worker數 
  24.  
  25. ... 
  26.  

1.3.3 FPM的初始化

接下來看下fpm的啟動流程,從main()函數開始:

  1. //sapi/fpm/fpm/fpm_main.c 
  2.  
  3. int main(int argc, char *argv[]) 
  4.  
  5.  
  6. ... 
  7.  
  8. //注冊SAPI:將全局變量sapi_module設置為cgi_sapi_module 
  9.  
  10. sapi_startup(&cgi_sapi_module); 
  11.  
  12. ... 
  13.  
  14. //執行php_module_starup() 
  15.  
  16. if (cgi_sapi_module.startup(&cgi_sapi_module) == FAILURE) { 
  17.  
  18. return FPM_EXIT_SOFTWARE; 
  19.  
  20.  
  21. ... 
  22.  
  23. //初始化 
  24.  
  25. if(0 > fpm_init(...)){ 
  26.  
  27. ... 
  28.  
  29.  
  30. ... 
  31.  
  32. fpm_is_running = 1; 
  33. //phpfensi.com 
  34. fcgi_fd = fpm_run(&max_requests);//后面都是worker進程的操作,master進程不會走到下面 
  35.  
  36. parent = 0; 
  37.  
  38. ... 
  39.  
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():

  1. static int sp[2]; 
  2.  
  3. int fpm_signals_init_main() 
  4.  
  5.  
  6. struct sigaction act; 
  7.  
  8. //創建一個全雙工管道 
  9.  
  10. if (0 > socketpair(AF_UNIX, SOCK_STREAM, 0, sp)) { 
  11.  
  12.     return -1; 
  13.  
  14.  
  15. //注冊信號處理handler 
  16.  
  17. act.sa_handler = sig_handler; 
  18.  
  19. sigfillset(&act.sa_mask); 
  20.  
  21. if (0 > sigaction(SIGTERM,  &act, 0) || 
  22.  
  23.     0 > sigaction(SIGINT,   &act, 0) || 
  24.  
  25.     0 > sigaction(SIGUSR1,  &act, 0) || 
  26.  
  27.     0 > sigaction(SIGUSR2,  &act, 0) || 
  28.  
  29.     0 > sigaction(SIGCHLD,  &act, 0) || 
  30.  
  31.     0 > sigaction(SIGQUIT,  &act, 0)) { 
  32.  
  33.     return -1; 
  34.  
  35.  
  36. return 0; 
  37.  

這里會通過socketpair()創建一個管道,這個管道并不是用于master與worker進程通信的,它只在master進程中使用,具體用途在稍后介紹event事件處理時再作說明。另外設置master的信號處理handler,當master收到SIGTERM、SIGINT、SIGUSR1、SIGUSR2、SIGCHLD、SIGQUIT這些信號時將調用sig_handler()處理:

  1. static void sig_handler(int signo) 
  2.  
  3.  
  4. static const char sig_chars[NSIG + 1] = { 
  5.  
  6. [SIGTERM] = 'T'
  7.  
  8. [SIGINT] = 'I'
  9.  
  10. [SIGUSR1] = '1'
  11.  
  12. [SIGUSR2] = '2'
  13.  
  14. [SIGQUIT] = 'Q'
  15.  
  16. [SIGCHLD] = 'C' 
  17.  
  18. }; 
  19.  
  20. char s; 
  21.  
  22. ... 
  23.  
  24. s = sig_chars[signo]; 
  25.  
  26. //將信號通知寫入管道sp[1]端 
  27.  
  28. write(sp[1], &s, sizeof(s)); 
  29.  
  30. ... 
  31.  

(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進程的。

  1. int fpm_run(int max_requests) 
  2.  
  3.  
  4. struct fpm_worker_pool_s wp; 
  5.  
  6. for (wp = fpm_worker_all_pools; wp; wp = wp->next) { 
  7.  
  8. //調用fpm_children_make() fork子進程 
  9.  
  10. is_parent = fpm_children_create_initial(wp); 
  11.  
  12.    if (!is_parent) { 
  13.  
  14.         goto run_child; 
  15.  
  16.     } 
  17.  
  18.  
  19. //master進程將進入event循環,不再往下走 
  20.  
  21. fpm_event_loop(0); 
  22.  
  23. run_child: //只有worker進程會到這里 
  24.  
  25. *max_requests = fpm_globals.max_requests; 
  26.  
  27. return fpm_globals.listening_socket; //返回監聽的套接字 
  28.  

在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)等待下一個請求。

  1. int main(int argc, char *argv[]) 
  2.  
  3.  
  4. ... 
  5.  
  6. fcgi_fd = fpm_run(&max_requests); 
  7.  
  8. parent = 0; 
  9.  
  10. //初始化fastcgi請求 
  11.  
  12. request = fpm_init_request(fcgi_fd); 
  13.  
  14.  
  15.  
  16. //worker進程將阻塞在這,等待請求 
  17.  
  18. while (EXPECTED(fcgi_accept_request(request) >= 0)) { 
  19.  
  20.     SG(server_context) = (void *) request; 
  21.  
  22.     init_request_info(); 
  23.  
  24.       
  25.  
  26.     //請求開始 
  27.  
  28.     if (UNEXPECTED(php_request_startup() == FAILURE)) { 
  29.  
  30.         ... 
  31.  
  32.     } 
  33.  
  34.     ... 
  35.  
  36.  
  37.  
  38.     fpm_request_executing(); 
  39.  
  40.     //編譯、執行PHP腳本 
  41.  
  42.     php_execute_script(&file_handle); 
  43.  
  44.     ... 
  45.  
  46.     //請求結束 
  47.  
  48.     php_request_shutdown((void *) 0); 
  49.  
  50.     ... 
  51.  
  52. //phpfensi.com 
  53. ... 
  54.  
  55. //worker進程退出 
  56.  
  57. php_module_shutdown(); 
  58.  
  59. ... 
  60.  

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():

  1. void fpm_event_loop(int err) 
  2.  
  3.  
  4. //創建一個io read的監聽事件,這里監聽的就是在fpm_init()階段中通過socketpair()創建管道sp[0] 
  5.  
  6. //當sp[0]可讀時將回調fpm_got_signal() 
  7.  
  8. fpm_event_set(&signal_fd_event, fpm_signals_get_fd(), FPM_EV_READ, &fpm_got_signal, NULL); 
  9.  
  10. fpm_event_add(&signal_fd_event, 0); 
  11.  
  12. //如果在php-fpm.conf配置了request_terminate_timeout則啟動心跳檢查 
  13.  
  14. if (fpm_globals.heartbeat > 0) { 
  15.  
  16.     fpm_pctl_heartbeat(NULL, 0, NULL); 
  17.  
  18.  
  19. //定時觸發進程管理 
  20.  
  21. fpm_pctl_perform_idle_server_maintenance_heartbeat(NULL, 0, NULL); 
  22.  
  23.  
  24.  
  25. //進入事件循環,master進程將阻塞在此 
  26.  
  27. while (1) { 
  28.  
  29.     ... 
  30.  
  31.     //等待IO事件 
  32.  
  33.     ret = module->wait(fpm_event_queue_fd, timeout); 
  34.  
  35.     ... 
  36.  
  37.     //檢查定時器事件 
  38.  
  39.     ... 
  40.  
  41.  

這就是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數量的控制,處理邏輯如下:

  1. static void fpm_pctl_perform_idle_server_maintenance(struct timeval now) 
  2.  
  3.  
  4. for (wp = fpm_worker_all_pools; wp; wp = wp->next) { 
  5.  
  6. struct fpm_child_s last_idle_child = NULL; //空閑時間最久的worker 
  7.  
  8. int idle = 0; //空閑worker數 
  9.  
  10. int active = 0; //忙碌worker數 
  11.  
  12.     for (child = wp->children; child; child = child->next) { 
  13.  
  14.         //根據worker進程的fpm_scoreboard_proc_s->request_stage判斷 
  15.  
  16.         if (fpm_request_is_idle(child)) { 
  17.  
  18.             //找空閑時間最久的worker 
  19.  
  20.             ... 
  21.  
  22.             idle++; 
  23.  
  24.         }else
  25.  
  26.             active++; 
  27.  
  28.         } 
  29.  
  30.     } 
  31.  
  32.     ... 
  33.  
  34.     //ondemand模式 
  35.  
  36.     if (wp->config->pm == PM_STYLE_ONDEMAND) { 
  37.  
  38.         if (!last_idle_child) continue
  39.  
  40.  
  41.  
  42.         fpm_request_last_activity(last_idle_child, &last); 
  43.  
  44.         fpm_clock_get(&now); 
  45.  
  46.         if (last.tv_sec < now.tv_sec - wp->config->pm_process_idle_timeout) { 
  47.  
  48.             //如果空閑時間最長的worker空閑時間超過了process_idle_timeout則殺掉該worker 
  49.  
  50.             last_idle_child->idle_kill = 1; 
  51.  
  52.             fpm_pctl_kill(last_idle_child->pid, FPM_PCTL_QUIT); 
  53.  
  54.         }  
  55.  
  56.         continue
  57.  
  58.     } 
  59.  
  60.     //dynamic 
  61.  
  62.     if (wp->config->pm != PM_STYLE_DYNAMIC) continue
  63.  
  64.     if (idle > wp->config->pm_max_spare_servers && last_idle_child) { 
  65.  
  66.         //空閑worker太多了,殺掉 
  67.  
  68.         last_idle_child->idle_kill = 1; 
  69.  
  70.         fpm_pctl_kill(last_idle_child->pid, FPM_PCTL_QUIT); 
  71.  
  72.         wp->idle_spawn_rate = 1; 
  73.  
  74.         continue
  75.  
  76.     } 
  77.  
  78.     if (idle < wp->config->pm_min_spare_servers) { 
  79.  
  80.         //空閑worker太少了,如果總worker數未達到max數則fork 
  81.  
  82.         ... 
  83.  
  84.     } 
  85.  
  86.  

(3)fpm_pctl_heartbeat():

這個事件是用于限制worker處理單個請求最大耗時的,php-fpm.conf中有一個request_terminate_timeout的配置項,如果worker處理一個請求的總時長超過了這個值那么master將會向此worker進程發送kill -TERM信號殺掉worker進程,此配置單位為秒,默認值為0表示關閉此機制,另外fpm打印的slow log也是在這里完成的。

  1. static void fpm_pctl_check_request_timeout(struct timeval now) 
  2.  
  3.  
  4. struct fpm_worker_pool_s wp; 
  5.  
  6. for (wp = fpm_worker_all_pools; wp; wp = wp->next) { 
  7.  
  8.     int terminate_timeout = wp->config->request_terminate_timeout; 
  9.  
  10.     int slowlog_timeout = wp->config->request_slowlog_timeout; 
  11.  
  12.     struct fpm_child_s *child; 
  13.  
  14.  
  15.  
  16.     if (terminate_timeout || slowlog_timeout) {  
  17.  
  18.         for (child = wp->children; child; child = child->next) { 
  19.  
  20.             //檢查當前當前worker處理的請求是否超時 
  21.  
  22.             fpm_request_check_timed_out(child, now, terminate_timeout, slowlog_timeout); 
  23.  
  24.         } 
  25.  
  26.     } 
  27.  
  28.  

除了上面這幾個事件外還有一個沒有提到,那就是ondemand模式下master監聽的新請求到達的事件,因為ondemand模式下fpm啟動時是不會預創建worker的,有請求時才會生成子進程,所以請求到達時需要通知master進程,這個事件是在fpm_children_create_initial()時注冊的,事件處理函數為fpm_pctl_on_socket_accept(),具體邏輯這里不再展開,比較容易理解。

到目前為止我們已經把fpm的核心實現介紹完了,事實上fpm的實現還是比較簡單的。

Tags: Fpm啟動機制

分享到:

六合图库图纸印刷网