标题:【Swoole系列3.2】Swoole 异步进程服务系统

文章目录
    分类:PHP 标签:Swoole

    Swoole 异步进程服务系统

    在了解了整个进程、线程、协程相关的知识后,我们再来看看在 Swoole 中是如何通过异步方式处理进程问题的,并且了解一下线程在 Swoole 中的作用。

    Server两种运行模式

    其实在之前的测试代码中,我们就已经见到过这两种模式了,只是当时没说而已。不管是 Http 还是 TCP 等服务中,我们都有第三个参数的存在,默认情况下,它会赋值为一个 SWOOLE_PROCESS 参数,因此,如果是默认情况下我们一般不会写这个参数。而另外一种模式就是 SWOOLE_BASE 。

    SWOOLE_BASE模式

    这种模式就是传统的异步非阻塞模式,它的效果和 Nginx 以及 Node.js 是完全一样的。在 Node.js 中,是通过一个主线线程来处理所有的请求,然后对 I/O 操作进行异步线程处理,避免创建、销毁线程以及线程切换的消耗。当 I/O 任务完成后,通过观察者执行指定的回调函数,并把这个完成的事件放到事件队列的尾部,等待事件循环。


    这个东西吧,要讲清楚,开一个大系列都不为过。但是如果你之前学习过一点 Node 的话,那么其实就很好理解。因为我们之前写的各种 Server 服务代码,其实和 Node 中写得基本完全一样。都是一个事件,然后监听成功后在回调函数中写业务代码。这就是通过回调机制来实现的异步非阻塞模式,将耗时操作放在回调函数中。有兴趣的同学可以去简单地学习一下 Node.js ,只要有 JS 基础,一两看看完一套入门教程就可以了。


    在 Swoole 的 SWOOLE_BASE 模式下,原理也是完全一样的。当一个请求进来的时候,所有的 Worker 都会争抢这一个连接,并最终会有一个 Worker 进程成功直接和客户端建立连接,之后这个连接中所有的数据收发直接和这个 Worker 通讯,不再经过主进程的 Reactor 线程转发。

    SWOOLE_PROCESS模式

    SWOOLE_PROCESS 的所有客户端都是和主进程建立的,内部实现比较复杂,用了大量的进程间通信、进程管理机制。适合业务逻辑非常复杂的场景,因为它可以方便地进行进程间的互相通信。


    在 SWOOLE_PROCESS 中,所有的 Worker 不会去争抢连接,也不会让某一个连接与某个固定的 Worker 通讯,而是通过一个主进程进行连接。剩下的事件处理则交给不同的 Worker 去执行,当到达 Worker 之后,同样地也是使用回调方式进行处理了,后续内容基本就和 BASE 差不多了。也就是说,Worker 功能的不同是它和 SWOOLE_BASE 最大的差异,它实现了连接与数据请求的分离,不会因为某些连接数据量大某些量小导致 Worker 进程不均衡。具体的方式就是在这种模式下,会多出来一个主管线程的进程,其中还会有一个非常重要的 Reactor 线程,下面我们再详细说明。

    两种模式的异同与优缺点

    如果客户端之间不需要交互,也就是我们普通的 HTTP 服务的话,SWOOLE_BASE 模式是一个很好的选择,但是它除了 send() 和 close() 方法之外,不支持跨进程执行。但其实,这两种模式在底层的处理上没什么太大的区别,都是走的异步IO机制。只是说它们的连接方式不同。SWOOLE_BASE 的每个 Worker 都可以看成是 SWOOLE_PROCESS 的 Reactor 线程和 Worker 进程两部分的组合。


    我们可以来测试一下。

    $http = new Swoole\Http\Server('0.0.0.0', 9501, SWOOLE_BASE);
    
    //$http = new Swoole\Http\Server('0.0.0.0', 9501, SWOOLE_PROCESS);
    
    $http->set([
        'worker_num'=>2
    ]);
    
    $http->on('Request', function ($request, $response) {
        var_dump(func_get_args());
        $response->end('开始测试');
    });
    
    $http->start();

    通过切换上面两个注释,我们就可以查看两种服务运行模式的情况,可以通过 pstree -p 命令。


    在 SWOOLE_BASE 模式下,输出的内容是这样的。


    //img1.zyblog.com.cn/20220723/4bb99d02fd10382b82d0c527a0d23b0c.png


    可以看到,在 1629 这个进程下面有两个子进程 1630 和 1631 。然后切换成 SWOOLE_PROCESS 模式,再查看进程情况。


    //img1.zyblog.com.cn/20220723/d127426c4bc2ec11836f949698a7dc69.png


    很明显,这里不一样了,在 1577 这个 Master 主进程下,有两个进程,一个是 1578 ,一个是 1579 它表示的是线程组,然后在 1578 Manager 管理进程下面,又有 1580 和 1581 两个 Worker 进程。


    同样地,我们使用之前在 【Swoole教程2.5】异步任务https://mp.weixin.qq.com/s/bQt9Ul-H34eUYw2-Qu-N0g 中的代码来测试,可以看到 Task 异步任务也是起的进程。(注意,我们在测试代码中设置的是 task_worker_num,没有设置 worker_num ,所以是 1个Worker + 4个 TaskWorker 进程,最后再加一个 PROCESS 模式的 线程组 )如果如图所示。


    //img1.zyblog.com.cn/20220723/0e7eeb259f2d81f38da41802a7d09bd3.png


    到这里,相信你也看出了,SWOOLE_BASE 比 SWOOLE_PROCESS 少了一层进程的递进,也就是少了一个层级。在 SWOOLE_BASE 模式下,没有 Master 进程,只有一个 Manager 进程,另外就是没有从 Master 中分出来的线程组。关于 Master/Manager/Reactor/TaskWorker 这些东西我们下一小节就会说到。


    BASE 模式因为更简单,所以不容易出错,它也没有 IPC 开销,而 PROCESS 模式有 2 次 IPC 开销,master 进程与 worker 进程需要 Unix Socket 进行通信。IPC 这东西就是同一台主机上两个进程间通信的简称。它一般有两种形式,一个是通过 Unix Socket 的方式,就是我们最常见的类似于 php-fcgi.sock 或者 mysql.sock 那种东西。另一种就是 sysvmsg 形式,这是 Linux 提供的一种消息队列,一般使用的比较少。


    当然,BASE 模式也有它自身存在的问题,主要也是因为上面讲过的特性。由于 Worker 是和连接绑定的,因此,某个 Worker 挂掉的话,这个 Worker 里面的所有连接都会被关闭。另外由于争抢的情况,Worker 进程无法实现均衡,有可能有些连接数据量小,负载也会非常低。最后,如果回调函数中阻塞操作,会导致 Server 退化为同步模式,容易导致 TCP 的 backlog 队列塞满。不过就像上面说过的,Http 这种无状态的不需要交互的连接,使用 BASE 没什么问题,而且效率也是非常 OK 的。当然,既然默认情况下 Swoole 已经为我们提供的是 SWOOLE_PROCESS 进程了,那么也就说明 SWOOLE_PROCESS 模式是更加推荐的一种模式。

    各种进程问题

    接下来,我们继续学习上面经常会提到的各种进程和线程问题。

    Master 进程

    它是一个多线程进程。用于管理线程,它会创建 Master 线程以及 Reactor 线程,并且还有心跳检测线程、UDP 收包线程等等。

    Reactor 线程

    这个线程我们不止一次提到了,它是在 Master 进程中创建的,负责客户端 TCP 连接、处理网络 IO 、处理协议、收发数据,它不执行任何 PHP 代码,用于将 TCP 客户端发来的数据缓冲、拼接、拆分成完整的一个请求数据包。我们在 Swoole 代码中操作不了线程,为什么呢?其实 PHP 本身就是不支持多线程的,Swoole 是一种多进程应用框架。在这里的线程是在底层用 C/C++ 封装好的。因此,也并没有为我们提供可以直接操作线程的接口。但我们已经学习过了,协程本身就是工作在线程之上的,而且,协程也已经是现在的主流方向了,所以在 Swoole 中,进程管理和协程,才是我们学习的重点。

    Worker 进程

    Worker 是接受 Reactor 线程投递过来的请求数据包,并执行具体的 PHP 回调函数来进行数据处理的。在处理完成之后,将生成的响应数据发送回 Reactor 线程,再由 Reactor 发送给客户端。Worker 进程可以是异步非阻塞模式的,也可以是同步阻塞模式的,并且是以多进程方式运行的。

    TaskWorker 进程

    它是接受收 Worker 进程投递过来的任务,处理任务后将结果返回给 Worker 进程,这种模式是同步阻塞的模式,同样它也是以多进程的方式运行的。

    Manager 进程

    这个进程主要负责创建、回收 Worker/TaskWorkder 进程。其实就是一个进程管理器。

    它们的关系

    首先,我们先来看两张图,也是官网给出的图,并根据这两张图再来看看官网给出的例子。


    //img1.zyblog.com.cn/20220723/e12ac398aebc71293967ee66dc16914e.png


    第一张图主要是 Manager 和 Master 的功能。我们主要看第二张图。


    //img1.zyblog.com.cn/20220723/6be4c7cfb13d47b16d5cf084a1149ab2.png


    在这张图中,我们可以看到,Manager 进程创建、回收、管理最下面的 Worker 进程和 Task 进程。并且是通过操作系统的 fork() 函数创建的,这个东西如果学过操作系统的同学应该不会陌生,fork() 就是创建子进程的函数。子进程间通过 Unix Socket 或者 MQ 队列进行通信。如果你是 BASE 模式,那么就不会有 Master 进程,这个时候,每一个 Worker 进程自己会承担起 Reactor 的功能,接收、响应请求数据。


    如果你是使用的 PROCESS 模式,那么上面的 Master 进程就会创建各种线程,还记得那个大括号的线程组吧,这个可是 BASE 模式没有的。它用于处理请求响应问题,不用想,多线程方式对于连接请求来说效率会更高。这也是前面说过的两种模式的优缺点的具体体现。然后 Reactor 线程通过 Unix Socket 与 Worker 进行通讯,完成数据向 Worker 的转发与接收。


    我们用官网给出的例子来再说明一下它们之间的关系。Reactor 就是 nginx,Worker 就是 PHP-FPM 。Reactor 线程异步并行地处理网络请求,然后再转发给 Worker 进程中去处理。Reactor 和 Worker 间通过 Unix Socket 进行通信。


    在 PHP-FPM 的应用中,经常会将一个任务异步投递到 Redis 等队列中,并在后台启动一些 PHP 进程异步地处理这些任务。这个场景相信大家都不会陌生吧,比如说我们下了订单之后,在原生 PHP 环境下进行消息通知、邮件发送,我们都会直接将这种问题放到一个队列中,然后让后台跑起一个脚本去消费这些队列从而进行信息发送。而 Swoole 提供的 TaskWorker 则是一套更完整的方案,将任务的投递、队列、PHP 任务处理进程管理合为一体。通过底层提供的 API 可以非常简单地实现异步任务的处理。另外 TaskWorker 还可以在任务执行完成后,再返回一个结果反馈到 Worker。


    一个更通俗的比喻,假设 Server 就是一个工厂,那 Reactor 就是销售,接受客户订单。而 Worker 就是工人,当销售接到订单后,Worker 去工作生产出客户要的东西。而 TaskWorker 可以理解为行政人员,可以帮助 Worker 干些杂事,让 Worker 专心工作。


    上述内容需要好好理解,特别是对于我们些长年接触传统的 PHP-FPM 模式开发的同学来说,要转换思维很不容易。不过根据官方提供的例子,相信大家也能很快把这个弯转过来。普通的请求就是把我们的 Nginx+PHP-FPM 给结合起来了,而 Task 则是可以处理一些类似于消息队列的异步操作。

    Swoole 服务运行流程

    最后,我们再来了解一下整体 Swoole 服务的运行流程,同样也是来自官网的图片。


    //img1.zyblog.com.cn/20220723/87436bc81eee5015280c47f506b93e8a.png


    其实这个流程图和我们的代码流程非常类似。定义一个 Server 对象,使用 set() 方法设置参数,然后使用 on() 方法开始监听各种回调,最后 start() 方法启动服务。在服务启动之后,创建了 Manager 进程,如果是 PROCESS 模式的话,则是先创建一个 Master 进程,然后在 Master 之下创建 Manager 。接着,Manager 根据 worker_num 数量创建并管理相对应数量的 Worker 进程。其中,可以在 Worker 中创建异步的 task 进程。


    Reactor 线程在最外面处理请求响应问题,监听相对应的事件,并与 Worker 进行通信。如果是 BASE 模式,不存在 Reactor 线程,则是全部由 Worker 来解决,而且它与连接的关系是一对一的。

    总结

    又是让人晕头转向的一篇文章吧。在今天的学习中,最主要的其实还是一种思维的转变,那就是我们要通过多进程的方式来提供服务应用。而且这种模式其实并不陌生,Nginx+PHP-FPM 就是这种模式,只不过,PHP-FPM 本身就是一个进程管理工具,但它的效率以及实现方式都与 Swoole 略有差别。包括在 PHP8 之后的 JIT ,它就是通过 OPCahce 来实现的,也是在将大部分代码全部一次加载到内存中,就像 Swoole 一样节约每次 PHP-FPM 的全量加载问题从而提升性能。


    好好消化吸收一下吧,不过同样的,如果上述内容有错误纰漏,随时欢迎大家指正批评,毕竟水平有限。


    测试代码:


    https://github.com/zhangyue0503/swoole/blob/main/3.Swoole%E8%BF%9B%E7%A8%8B/source/3.2Swoole%E5%BC%82%E6%AD%A5%E8%BF%9B%E7%A8%8B%E7%B3%BB%E7%BB%9F.php


    参考文档:


    https://wiki.swoole.com/#/server/init


    https://wiki.swoole.com/#/learn?id=process-diff

    视频链接

    微信文章地址:https://mp.weixin.qq.com/s/raIfojXP7u1CPD9cpj7g5A

    微信视频地址:https://mp.weixin.qq.com/s/pyF9b8A-7QPrNNHdkNRuQw

    B站视频地址:https://www.bilibili.com/video/BV1nG411g7zy/

    搜索
    关注