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
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組成一個單鏈表
1.3.3 FPM的初始化
接下來看下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進程的後續操作。
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)等待下一個請求。
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()：
這就是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數量的控制