初識server一文的時候我們說過，swoole是事件驅動的。在使用swoole的過程中，我們也體會到，swoole的使用非常簡單，僅僅注冊相應的回調處理我們的業(yè)務邏輯即可。

但是，在繼續(xù)學習swoole之前，我們有必要再看一看swoole的運行流程和進程模型。

推薦（免費）：swoole

前面兩篇文章我們已經(jīng)對server和task做了簡單的介紹，后面再對server的創(chuàng)建以及腳本的執(zhí)行，如無特殊說明均在CLI下執(zhí)行，我就不啰嗦了。

現(xiàn)在，我們創(chuàng)建一個簡單的server來分析一下，文件命名為server-process.php

$serv = new swoole_server('127.0.0.1', 9501); $serv->set([     'worker_num' => 2,     'task_worker_num' => 1, ]); $serv->on('Connect', function ($serv, $fd) { }); $serv->on('Receive', function ($serv, $fd, $fromId, $data) { }); $serv->on('Close', function ($serv, $fd) { }); $serv->on('Task', function ($serv, $taskId, $fromId, $data) { }); $serv->on('Finish', function ($serv, $taskId, $data) { });  $serv->start();

注意這里我們選擇了兩個worker進程個一個task進程，那是不是就意味著創(chuàng)建這個server就是開啟了3個進程呢？我們來看下

新開一個終端，我們用ps命令看下結果

$ ps aux | grep server-process root     21843  xxx... php server-process.php root     21844  xxx... php server-process.php root     21846  xxx... php server-process.php root     21847  xxx... php server-process.php root     21848  xxx... php server-process.php root     21854  xxx... grep --color=auto server-process

為了方便閱讀，ps的結果中部分不重要數(shù)據(jù)已經(jīng)被稍加處理了。

排除最后一個結果（最后一個是我們運行的ps命令）我們發(fā)現(xiàn)，竟然有多達5個相似的進程在運行，按照我們理解，不應該是3個嗎，怎么多了兩個呢？

還記得我們在進程/線程一文中說過的多進程的實現(xiàn)嗎？我們說到多進程的實現(xiàn)一般會被設計Master-Worker模式，常見的nginx默認的多進程模式也正是如此，當然swoole默認的也是多進程模型。

相比Master-Worker模式，swoole的進程模型可以用Master-Manager-Worker來形容。即在Master-Worker的基礎上又增加了一層Manager進程。這也就解答了我們開頭拋出的問題為什么是5個進程而不是3個進程了。（1個Master進程+1個Manager進程+2個Worker進程+1個Task進程）

正所謂“存在即合理”，我們來看一下MasterManagerWorker三種進程各自存在的原因。

Master進程是一個多線程程序。注解：按照我們之前的理解，多個線程是運行在單一進程的上下文中的，其實對于單一進程中的每一個線程，都有它自己的上下文，但是由于共同存在于同一進程，所以它們也共享這個進程，包括它的代碼、數(shù)據(jù)等等。

再回來繼續(xù)說Master進程，Master進程就是我們的主進程，掌管生殺大權，它掛了，那底下的都得玩完。Master進程，包括主線程，多個Reactor線程等。

每一個線程都有自己的用途，比如主線程用于Accept、信號處理等操作，而Reactor線程是處理tcp連接，處理網(wǎng)絡IO，收發(fā)數(shù)據(jù)的線程。

說明兩點：

• 主線程的Accept操作，socket服務端經(jīng)常用accept阻塞，上一節(jié)介紹socket編程的時候有一張配圖，可以看看
• 信號處理，信號就相當于一條消息，比如我們經(jīng)常操作的Ctrl+C其實就是給Master進程的主線程發(fā)送一個SIGINT的信號，意思就是你可以終止啦，信號有很多種，后面還有介紹

通常，主線程處理完新的連接后，會將這個連接分配給固定的Reactor線程，并且這個Reactor線程會一直負責監(jiān)聽此socket（上文中后面對socket更新為socket即套接字，是用來與另一個進程進行跨網(wǎng)絡通信的文件，文件可讀可寫），換句話就是說當此socket可讀時，會讀取數(shù)據(jù)，并將該請求分配給worker進程，這也就解釋了我們在swoole初識講解worker進程內的回調onReceive的第三個參數(shù)$fromId的含義；當此socket可寫時，會把數(shù)據(jù)發(fā)送給tcp客戶端。

用一張圖清晰的梳理下

那swoole為啥不能像Nginx一樣，是Master-Worker進程結構的呢？Manager進程是干啥的？

這個我正準備說。

我們知道，在Master-Worker模型中，Master只有一個，Worker是由父進程Master進程復制出來的，且Worker進程可以有多個。

注解：在linux中，父進程可以通過調用fork函數(shù)創(chuàng)建一個新的子進程，子進程是父進程的一個副本，幾乎但不完全相同，二者的最大區(qū)別就是都擁有自己獨立的進程ID，即PID。

對于多線程的Master進程而言，想要多Worker進程就必須fork操作，但是fork操作是不安全的，所以，在swoole中，有一個專職的Manager進程，Manager進程就專門負責worker/task進程的fork操作和管理。換句話也就是說，對于worker進程的創(chuàng)建、回收等操作全權有“保姆”Manager進程進行管理。

通常，worker進程被誤殺或者由于程序的原因會異常退出，Manager進程為了保證服務的穩(wěn)定性，會重新拉起新的worker進程，意思就是Worker進程你發(fā)生意外“死”了，沒關系，我自身不“死”，就可以fork千千萬萬個你。

當然，Master進程和Manager進程我們是不怎么關心的，從前面兩篇文章我們了解到，真正實現(xiàn)業(yè)務邏輯，是在worker/task進程內完成的。

再來一張圖梳理下Manager進程和Worker/Task進程的關系。

再回到我們開篇拋出的的5個進程的問題，ps的結果簡直一模一樣，有沒有辦法能區(qū)分這5個進程哪個是哪個呢？

有同學要說啦，既然各個進程之間存在父子關系，那我們就可以通過linux的pstree命令查看結果。

$ pstree | grep server-process   | |   -+= 02548 manks php server-process.php   | |     -+- 02549 manks php server-process.php   | |       |--- 02550 manks php server-process.php   | |       |--- 02551 manks php server-process.php   | |       --- 02552 manks php server-process.php   |     --- 02572 manks grep server-process

注：centos下命令可修改為 pstree -ap | grep server-process

從結果中我們可以看出，進程id等于02548的進程就是Master進程，因為從結構上看就它是“父”嘛，02549是Manager進程，Worker進程和Task進程就是02550、02551和02552了（每個人的電腦上顯示的進程id可能不同，但順序是一致的，依照此模型分析即可）。

我們看到pstree命令也只能得到大致結果，而且在事先不知道的情況下，根本無法區(qū)分Worker進程和Task進程。

在swoole中，我們可以在各個進程啟動和關閉的回調中去解決上面這個問題。各個進程的啟動和關閉？那豈不是又要記住主進程、Manager進程、Worker進程，二三得六，6個回調函數(shù)?

是的，不過這6個是最簡單也是最好記的，你實際需要了解的可能還要