Heim >PHP-Framework >Swoole >Einführung in das Prozessmodell von Swoole
Als wir den Server-Artikel zum ersten Mal trafen, sagten wir, dass Swoole ereignisgesteuert ist. Bei der Verwendung von Swoole haben wir auch festgestellt, dass die Verwendung von Swoole sehr einfach ist. Wir müssen nur den entsprechenden Rückruf registrieren, um unsere Geschäftslogik zu verarbeiten.
Bevor wir jedoch mit dem Erlernen von Swoole fortfahren, müssen wir uns noch einmal den Betriebsablauf und das Prozessmodell von Swoole ansehen.
Empfohlen (kostenlos): swoole
In den ersten beiden Artikeln haben wir kurz die Erstellung von Servern und die Ausführung von Skripten erläutert Unter der CLI werde ich nicht ausführlich sein.
Jetzt erstellen wir einen einfachen Server zur Analyse. Die Datei heißt 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();. Beachten Sie, dass wir hier zwei Worker-Prozesse und einen Task-Prozess ausgewählt haben etwa 3 Prozesse? Werfen wir einen Blick darauf Öffnen Sie ein neues Terminal und verwenden Sie den ps-Befehl, um die Ergebnisse anzuzeigen$ 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-processZur besseren Lesbarkeit wurden einige unwichtige Daten in den ps-Ergebnissen leicht verarbeitet. Mit Ausnahme des letzten Ergebnisses (das letzte ist der von uns ausgeführte ps-Befehl) haben wir festgestellt, dass nach unserem Verständnis nicht mehr als 3 weitere Prozesse ausgeführt werden. Erinnern Sie sich an die Implementierung von Multiprozessen, über die wir im Artikel Prozess/Thread gesprochen haben? Wenn wir über die Implementierung von Multiprozessen sprechen, ist der allgemeine Standard-Multiprozessmodus von Nginx genau derselbe. Natürlich ist das Standard-Multiprozessmodell von Swoole auch der Multiprozessmodus. Prozessmodell. Im Vergleich zum Master-Worker-Modell kann das Prozessmodell von Swoole als Master-Manager-Worker beschrieben werden. Das heißt, es wird eine zusätzliche Ebene des Manager-Prozesses auf der Basis von Master-Worker hinzugefügt. Damit ist auch die eingangs aufgeworfene Frage beantwortet: Warum gibt es 5 statt 3 Prozesse? (1 Master-Prozess + 1 Manager-Prozess + 2 Worker-Prozesse + 1 Task-Prozess) Wie das Sprichwort sagt „Existenz ist vernünftig“, werfen wir einen Blick auf die Gründe, warum die drei Prozesse von MasterManagerWorker existieren. Der Master-Prozess ist ein Multithread-Programm. Hinweis: Nach unserem bisherigen Verständnis laufen mehrere Threads im Kontext eines einzelnen Prozesses. Tatsächlich hat jeder Thread in einem einzelnen Prozess seinen eigenen Kontext, aber da sie im selben Prozess koexistieren, teilen sie ihn auch. einschließlich seines Codes, seiner Daten usw. Kommen wir zurück und sprechen weiter über den Master-Prozess. Der Master-Prozess ist unser Hauptprozess und entscheidet über Leben und Tod. Wenn er stirbt, muss alles andere unten abgeschlossen werden. Master-Prozess, einschließlich Haupt-Thread, mehreren Reaktor-Threads usw. Jeder Thread hat seinen eigenen Zweck. Der Hauptthread wird beispielsweise zum Akzeptieren, zur Signalverarbeitung und für andere Vorgänge verwendet, während der Reaktorthread der Thread ist, der TCP-Verbindungen verarbeitet, Netzwerk-E/A verarbeitet und Daten sendet und empfängt. Erklären Sie zwei Punkte:
Warum kann Swoole dann nicht eine Master-Worker-Prozessstruktur wie Nginx haben? Was macht der Manager-Prozess? 
通常，worker进程被误杀或者由于程序的原因会异常退出，Manager进程为了保证服务的稳定性，会重新拉起新的worker进程，意思就是Worker进程你发生意外“死”了，没关系，我自身不“死”，就可以fork千千万万个你。
当然，Master进程和Manager进程我们是不怎么关心的，从前面两篇文章我们了解到，真正实现业务逻辑，是在worker/task进程内完成的。
再来一张图梳理下Manager进程和Worker/Task进程的关系。
再回到我们开篇抛出的的5个进程的问题，ps的结果简直一模一样，有没有办法能区分这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命令也只能得到大致结果，而且在事先不知道的情况下，根本无法区分Worker进程和Task进程。
在swoole中，我们可以在各个进程启动和关闭的回调中去解决上面这个问题。各个进程的启动和关闭？那岂不是又要记住主进程、Manager进程、Worker进程，二三得六，6个回调函数?
是的，不过这6个是最简单也是最好记的，你实际需要了解的可能还要更多。
Master进程：
启动：onStart
关闭：onShutdown
Manager进程：
启动：onManagerStart
关闭：onManagerStop
Worker进程：
启动：onWorkerStart
关闭：onWorkerStop提醒：task_worker也会触发onWorkerStart回调。
是不是很好记？那我们就在server-process.php中通过上面这几种回调来实现对各个进程名的修改。
$serv->on("start", function ($serv){
swoole_set_process_name('server-process: master');
});
// 以下回调发生在Manager进程
$serv->on('ManagerStart', function ($serv){
swoole_set_process_name('server-process: manager');
});
$serv->on('WorkerStart', function ($serv, $workerId){
if($workerId >= $serv->setting['worker_num']) {
swoole_set_process_name("server-process: task");
} else {
swoole_set_process_name("server-process: worker");
}
});注意：因mac下不支持swoole_set_process_name函数，即不能修改进程名，我们换台centos运行下看看结果（实际上你的服务器也不可能是mac）
# ps aux | grep server-process root 27546 xxx... server-process: master root 27547 xxx... server-process: manager root 27549 xxx... server-process: task worker root 27550 xxx... server-process: worker root 27551 xxx... server-process: worker root 27570 xxx... grep --color=auto simple
运行结果谁是谁一目了然，简直了！
有同学傻眼了，说在workerStart回调中写的看不明白，worker进程和task进程怎么区分的？
我来解释一下：在onWorkerStart回调中，$workerId表示的是一个值，这个值的范围是0~worker_num，worker_num是我们的对worker进程的配置，其中0~worker_num表示worker进程的标识，包括0但不包括worker_num；worker_num~worker_num+task_worker_num是task进程的标识,包括worker_num不包括worker_num+task_worker_num。
按照高中学的区间的知识可能更好理解，以我们案例的配置，workerId的值的范围就是[0,2]，[0,2)表示worker进程，[2,3)就表示task_worker进程。
swoole的进程模型很重要，本篇掌握不好，后面的理解可能就会有些问题。
我们在onWorkerStart的回调中，用了serv−>setting去获取配置的server信息，在swoole中预留了一些swooleserver的属性，我们可以在回调函数中访问。比如说我们可以用serv−>setting去获取配置的server信息，在swoole中预留了一些swooleserver的属性，我们可以在回调函数中访问。比如说我们可以用serv->connections属性获取当前server的所有的连接，再比如我们可以通过$serv->master_pid属性获取当前server的主进程id等等。
Das obige ist der detaillierte Inhalt vonEinführung in das Prozessmodell von Swoole. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!