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：

[web1] listen = 127.0.0.1:9000 ...

[web2] listen = 127.0.0.1:9001 ... 啓動fpm後查看進程：ps -aux|grep fpm

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

struct fpm_worker_pool_s { struct fpm_worker_pool_s *next; //指向下一個worker pool struct fpm_worker_pool_config_s *config; //conf配置:pm、max_children、start_servers... int listening_socket; //監聽的套接字 ...

//如下這個值用於master定時檢查、記錄worker數
struct fpm_child_s *children; //當前pool的worker鏈表
int running_children; //當前pool的worker運行總數
int idle_spawn_rate;
int warn_max_children;

struct fpm_scoreboard_s *scoreboard; //記錄worker的運行信息，好比空閒、忙碌worker數
...

} 1.3.3 FPM的初始化 接下來看下fpm的啓動流程，從main()函數開始：

//sapi/fpm/fpm/fpm_main.c int main(int argc, char *argv[]) { ... //註冊SAPI:將全局變量sapi_module設置爲cgi_sapi_module sapi_startup(&cgi_sapi_module); ... //執行php_module_starup() if (cgi_sapi_module.startup(&cgi_sapi_module) == FAILURE) { return FPM_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():

static int sp[2];

int fpm_signals_init_main() { struct sigaction act;

//建立一個全雙工管道
if (0 > socketpair(AF_UNIX, SOCK_STREAM, 0, sp)) {
    return -1;
}
//註冊信號處理handler
act.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;
}
return 0;

} 這裏會經過socketpair()建立一個管道，這個管道並非用於master與worker進程通訊的，它只在master進程中使用，具體用途在稍後介紹event事件處理時再做說明。另外設置master的信號處理handler，當master收到SIGTERM、SIGINT、SIGUSR一、SIGUSR二、SIGCHLD、SIGQUIT這些信號時將調用sig_handler()處理：

static void sig_handler(int signo) { static const char sig_chars[NSIG + 1] = { [SIGTERM] = 'T', [SIGINT] = 'I', [SIGUSR1] = '1', [SIGUSR2] = '2', [SIGQUIT] = 'Q', [SIGCHLD] = 'C' }; char s; ... 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進程的。

int fpm_run(int *max_requests) { struct fpm_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) {
        goto run_child;
    }
}
//master進程將進入event循環，再也不往下走
fpm_event_loop(0);

run_child: //只有worker進程會到這裏

*max_requests = fpm_globals.max_requests;
return fpm_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)等待下一個請求。 int main(int argc, 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_module_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()：

void fpm_event_loop(int err) { //建立一個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 = module->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進程由於異常緣由(好比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數量的控制，處理邏輯以下：

static void fpm_pctl_perform_idle_server_maintenance(struct timeval *now) { for (wp = fpm_worker_all_pools; wp; wp = wp->next) { struct fpm_child_s *last_idle_child = NULL; //空閒時間最久的worker int idle = 0; //空閒worker數 int active = 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則殺掉該worker
            last_idle_child->idle_kill = 1;
            fpm_pctl_kill(last_idle_child->pid, FPM_PCTL_QUIT);
        } 
        continue;
    }
    //dynamic
    if (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也是在這裏完成的。

static void fpm_pctl_check_request_timeout(struct timeval *now) {
struct fpm_worker_pool_s *wp;

for (wp = fpm_worker_all_pools; wp; wp = wp->next) {
    int terminate_timeout = wp->config->request_terminate_timeout;
    int slowlog_timeout = wp->config->request_slowlog_timeout;
    struct fpm_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的實現仍是比較簡單的。

轉載：https://github.com/pangudashu/php7-internal/blob/master/1/fpm.md