Swoole의 프로세스 모델을 소개합니다

서버 기사를 처음 만났을 때 스울레는 이벤트 중심이라고 했습니다. swoole을 사용하는 과정에서 우리는 swoole을 사용하는 것이 매우 간단하다는 것을 깨달았습니다. 비즈니스 로직을 처리하려면 해당 콜백만 등록하면 됩니다.

그러나 Swoole을 계속 배우기 전에 Swoole의 운영 프로세스와 프로세스 모델을 다시 한 번 살펴볼 필요가 있습니다.

추천(무료): swoole

처음 두 글에서는 서버와 작업에 대해 간략하게 소개했습니다. 이후에는 별도로 명시하지 않는 한 서버 생성 및 스크립트 실행에 대해 설명하겠습니다. CLI에서는 장황하지 않습니다.

이제 분석할 간단한 서버를 만들어 보겠습니다. 파일 이름은 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();

여기서는 두 개의 작업자 프로세스와 하나의 작업 프로세스를 선택했습니다. 그러면 이 서버를 만든다는 뜻인가요? 프로세스가 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 결과에서 중요하지 않은 일부 데이터를 약간 처리했습니다.

마지막 결과를 제외하면(마지막 것은 우리가 실행한 ps 명령입니다) 우리가 이해한 바에 따르면 유사한 프로세스가 5개나 더 실행되고 있는 것으로 나타났습니다. 왜 2개가 더 있어야 할까요?

프로세스/스레드 기사에서 다룬 다중 프로세스 구현을 기억하시나요? 다중 프로세스 구현에 관해 이야기할 때 일반적으로 Master-Worker 모드가 설계됩니다. nginx의 일반적인 기본 다중 프로세스 모드는 물론 swoole의 기본 다중 프로세스 모델도 다중 프로세스입니다. 프로세스 모델.

Master-Worker 모델에 비해 Swoole의 프로세스 모델은 Master-Manager-Worker로 설명할 수 있습니다. 즉, Master-Worker를 기반으로 Manager 프로세스의 추가 레이어가 추가됩니다. 이는 또한 우리가 처음에 제기한 질문, 즉 왜 3개의 프로세스가 아닌 5개의 프로세스가 있는지에 대한 답이기도 합니다. (마스터 프로세스 1개 + 매니저 프로세스 1개 + 워커 프로세스 2개 + 태스크 프로세스 1개)

'존재는 합리적이다'라는 말이 있듯이 MasterManagerWorker의 3가지 프로세스가 존재하는 이유를 살펴보겠습니다.

마스터 프로세스는 다중 스레드 프로그램입니다. 참고: 이전 이해에 따르면 여러 스레드는 단일 프로세스의 컨텍스트에서 실행됩니다. 실제로 단일 프로세스의 각 스레드는 자체 컨텍스트를 갖지만 동일한 프로세스에 공존하므로 이 프로세스도 공유합니다. 코드, 데이터 등을 포함합니다.

다시 돌아와서 마스터 프로세스에 대해 계속 이야기해 보겠습니다. 마스터 프로세스는 우리의 주요 프로세스이며 죽으면 아래의 모든 것이 완료되어야 합니다. 메인 스레드, 다중 Reactor 스레드 등을 포함한 마스터 프로세스

각 스레드에는 고유한 목적이 있습니다. 예를 들어 메인 스레드는 Accept, 신호 처리 및 기타 작업에 사용되는 반면 Reactor 스레드는 tcp 연결을 처리하고 네트워크 IO를 처리하며 데이터를 보내고 받는 스레드입니다.

두 가지 사항을 설명하세요.

• 메인 스레드의 Accept 작업, 소켓 서버는 종종 Accept를 사용하여 이전 섹션에서 소켓 프로그래밍을 소개할 때
• 신호 처리를 살펴볼 수 있습니다. 예를 들어 우리가 자주 사용하는 Ctrl+C는 실제로 마스터 프로세스의 메인 스레드에 SIGINT 신호를 보냅니다. 이는 마스터 프로세스를 종료할 수 있음을 의미하며 이에 대해서는 나중에 소개하겠습니다.

보통 메인 스레드는 연결이 이루어진 후 고정된 Reactor 스레드에 연결이 할당되고 이 Reactor 스레드는 항상 소켓 모니터링을 담당합니다(소켓은 위의 소켓으로 업데이트됩니다). (다른 프로세스와의 네트워크 간 통신에 사용되는 섹션) 파일은 파일을 읽고 쓸 수 있습니다. 즉, 소켓을 읽을 수 있으면 데이터를 읽고 요청을 작업자 프로세스에 할당합니다. 이것은 또한 우리가 swoole의 첫 번째 소개에서 작업자 프로세스를 설명한 이유를 설명합니다. 콜백 onReceive의 세 번째 매개변수 $fromId의 의미는 소켓이 쓰기 가능하면 데이터가 tcp 클라이언트로 전송됩니다.

사진으로 깔끔하게 정리해보자

그렇다면 왜 Nginx와 같은 Master-Worker 프로세스 구조를 가질 수 없는 걸까요? 관리자 프로세스는 무엇을 수행합니까?

이런 말을 하려던 참이었는데.

마스터-워커 모델에는 마스터가 하나만 있고 작업자는 상위 프로세스 마스터 프로세스에서 복사되며 여러 작업자 프로세스가 있을 수 있다는 것을 알고 있습니다.

참고: Linux에서 상위 프로세스는 포크 기능을 호출하여 새로운 하위 프로세스를 생성할 수 있습니다. 하위 프로세스는 상위 프로세스의 복사본이지만 거의 동일하지는 않습니다. 둘 사이의 가장 큰 차이점은 둘 다입니다. 자신만의 독립적인 프로세스 ID, 즉 PID를 가집니다.

멀티 스레드 Master 프로세스의 경우 여러 Worker 프로세스를 갖고 싶다면 작업을 포크해야 하지만 포크 작업은 안전하지 않습니다. 따라서 swoole에는 풀타임 Manager 프로세스가 있고 Manager 프로세스가 있습니다. 작업자/작업 프로세스 포크 운영 및 관리를 담당합니다. 즉, "nanny" Manager 프로세스는 작업자 프로세스의 생성, 재활용 및 기타 작업을 관리할 수 있는 모든 권한을 갖습니다.

通常，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等等。

위 내용은 Swoole의 프로세스 모델을 소개합니다의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!