引言

最近開發一個小功能，用到了隊列mcq，啟動一個進程消費隊列數據，后邊發現一個進程處理不過來了，又加了一個進程，過了段時間又處理不過來了......

這種方式每次都要修改crontab，如果進程掛掉了，不會及時的啟動，要等到下次crontab執行的時候才會啟動。關閉（重啟）進程的時候用的是kill，這可能會丟失正在處理的數據，比如下面這個例子，我們假設sleep過程就是處理邏輯，這里為了明顯看出效果，將處理時間放大到10s：

?php
$i = 1;
while (1) {
    echo "開始第[{$i}]次循環\n";
    sleep(10);
    echo "結束第[{$i}]次循環\n";
    $i++;
}

當我們運行腳本之后，等到循環開始之后，給進程發送kill {$pid}，默認發送的是編號為15的SIGTERM信號。假設$i是從隊列拿到的，拿到2的時候，正在處理，我們給程序發送了kill信號，和隊列數據丟失一樣，問題比較大，因此我要想辦法解決這些問題。

開始第[1]次循環

結束第[1]次循環

開始第[2]次循環

[1]    28372 terminated  php t.php

nginx進程模型

這時候我想到了nginx，nginx作為高性能服務器的中流砥柱，為成千上萬的企業和個人服務，他的進程模型比較經典，如下所示：

管理員通過master進程和nginx進行交互，從/path/to/nginx.pid讀取nginx master進程的pid，發送信號給master進程，master根據不同的信號做出不同的處理，然后反饋信息給管理員。worker是master進程fork出來的，master負責管理worker，不會去處理業務，worker才是具體業務的處理者，master可以控制worker的退出、啟動，當worker意外退出，master會收到子進程退出的消息，也會重新啟動新的worker進程補充上來，不讓業務處理受影響。nginx還可以平滑退出，不丟失任何一個正在處理的數據，更新配置時nginx可以做到不影響線上服務來加載新的配置，這在請求量很大的時候特別有用。

進程設計

看了nginx的進模型，我們完全可以開發一個類似的類庫來滿足處理mcq數據的需求，做到單文件控制所有進程、可以平滑退出、可以查看子進程狀態。不需要太復雜，因為我們處理隊列數據接收一定的延遲，做到nginx那樣不間斷服務比較麻煩，費時費力，意義不是很大。設計的進程模型跟nginx類似，更像是nginx的簡化版本。

進程信號量設計

信號量是進程間通訊的一種方式，比較簡單，單功能也比較弱，只能發送信號給進程，進程根據信號做出不同的處理。

master進程啟動的時候保存pid到文件/path/to/daeminze.pid，管理員通過信號和master進程通訊，master進程安裝3種信號，碰到不同的信號，做出不同的處理，如下所示：

SIGINT => 平滑退出，處理完正在處理的數據再退出

SIGTERM => 暴力退出，無論進程是否正在處理數據直接退出

SIGUSR1 => 查看進程狀態，查看進程占用內存，運行時間等信息

master進程通過信號和worker進程通訊，worker進程安裝了2個信號，如下所示：

SIGINT => 平滑退出

SIGUSR1 => 查看worker進程自身狀態

為什么worker進程只安裝2個信號呢，少了個SIGTERM，因為master進程收到信號SIGTERM之后，向worker進程發送SIGKILL信號，默認強制關閉進程即可。

worker進程是通過master進程fork出來的，這樣master進程可以通過pcntl_wait來等待子進程退出事件，當有子進程退出的時候返回子進程pid，做處理并啟動新的進程補充上來。

master進程也通過pcntl_wait來等待接收信號，當有信號到達的時候，會返回-1，這個地方還有些坑，在下文中會詳細講。

PHP中有2種信號觸發的方式，第一種方式是declare(ticks = 1);，這種效率不高，Zend每執行一次低級語句，都會去檢查進程中是否有未處理的信號，現在已經很少使用了，PHP 5.3.0及之前的版本可能會用到這個。

第二種是通過pcntl_signal_dispatch來調用未處理的信號，PHP 5.4.0及之后的版本適用，可以巧妙的將該函數放在循環中，性能上基本沒什么損失，現在推薦適用。

PHP安裝修信號量

PHP通過pcntl_signal安裝信號，函數聲明如下所示：

bool pcntl_signal ( int $signo , [callback $handler [, bool $restart_syscalls = true ] )

第三個參數restart_syscalls不太好理解，找了很多資料，也沒太查明白，經過試驗發現，這個參數對pcntl_wait函數接收信號有影響，當設置為缺省值true的時候，發送信號，進程用pcntl_wait收不到，必須設置為false才可以，看看下面這個例子：

?php
$i = 0;
while ($i5) {
    $pid = pcntl_fork();
    $random = rand(10, 50);
    if ($pid == 0) {
        sleep($random);
        exit();
    }
    echo "child {$pid} sleep {$random}\n";
    $i++;
}

pcntl_signal(SIGINT,  function($signo) {
     echo "Ctrl + C\n";
});

while (1) {
    $pid = pcntl_wait($status);
    var_dump($pid);
    pcntl_signal_dispatch();
}

運行之后，我們對父進程發送kill -SIGINT {$pid}信號，發現pcntl_wait沒有反應，等到有子進程退出的時候，發送過的SIGINT會一個個執行，比如下面結果：

child 29643 sleep 48

child 29644 sleep 24

child 29645 sleep 37

child 29646 sleep 20

child 29647 sleep 31

int(29643)

Ctrl + C

Ctrl + C

Ctrl + C

Ctrl + C

int(29646)

這是運行腳本之后馬上給父進程發送了四次SIGINT信號，等到一個子進程推出的時候，所有信號都會觸發。

但當把安裝信號的第三個參數設置為false：

pcntl_signal(SIGINT,  function($signo) {
     echo "Ctrl + C\n";
}, false);

這時候給父進程發送SIGINT信號，pcntl_wait會馬上返回-1，信號對應的事件也會觸發。

所以第三個參數大概意思就是，是否重新注冊此信號，如果為false只注冊一次，觸發之后就返回，pcntl_wait就能收到消息，如果為true，會重復注冊，不會返回，pcntl_wait收不到消息。

信號量和系統調用

信號量會打斷系統調用，讓系統調用立刻返回，比如sleep，當進程正在sleep的時候，收到信號，sleep會馬上返回剩余sleep秒數，比如：

?php
pcntl_signal(SIGINT,  function($signo) {
     echo "Ctrl + C\n";
}, false);

while (true) {
	pcntl_signal_dispatch();
    echo "123\n";
    $limit = sleep(2);
	echo "limit sleep [{$limit}] s\n";
}

運行之后，按Ctrl + C，結果如下所示：

123

^Climit sleep [1] s

Ctrl + C

123

limit sleep [0] s

123

^Climit sleep [1] s

Ctrl + C

123

^Climit sleep [2] s

daemon（守護）進程

這種進程一般設計為daemon進程，不受終端控制，不與終端交互，長時間運行在后臺，而對于一個進程，我們可以通過下面幾個步驟把他升級為一個標準的daemon進程：

protected function daemonize()
{
    $pid = pcntl_fork();
    if (-1 == $pid) {
        throw new Exception("fork進程失敗");
    } elseif ($pid != 0) {
        exit(0);
    }
    if (-1 == posix_setsid()) {
        throw new Exception("新建立session會話失敗");
    }

    $pid = pcntl_fork();
    if (-1 == $pid) {
        throw new Exception("fork進程失敗");
    } else if($pid != 0) {
        exit(0);
    }

    umask(0);
    chdir("/");
}

攏共分五步：

1.fork子進程，父進程退出。

2.設置子進程為會話組長，進程組長。

3.再次fork，父進程退出，子進程繼續運行。

4.恢復文件掩碼為0。

5.切換當前目錄到根目錄/。

第2步是為第1步做準備，設置進程為會話組長，必要條件是進程非進程組長，因此做第一次fork，進程組長（父進程）退出，子進程通過posix_setsid()設置為會話組長，同時也為進程組長。

第3步是為了不讓進程重新控制終端，因為一個進程控制一個終端的必要條件是會話組長（pid=sid）。

第4步是為了恢復默認的文件掩碼，避免之前做的操作對文件掩碼做了設置，帶來不必要的麻煩。關于文件掩碼， linux中，文件掩碼在創建文件、文件夾的時候會用到，文件的默認權限為666，文件夾為777，創建文件（夾）的時候會用默認值減去掩碼的值作為創建文件（夾）的最終值，比如掩碼022下創建文件666 - 222 = 644，創建文件夾777 - 022 = 755：