Swoole进程结构 Swoole进程结构一、进程的基本知识什么是进程，所谓进程其实就是操作系统中一个正在运行的程序，我们在一个终端当中，通过php，运行一个php文件，这个时候就相当于我们创建了一个进程，这个进程会在系统中驻存，申请属于它自己的内存空间系统资源并且运行相应的程序对于一个进程来说，它的核心内容分为两个部分，一个是它的内存，这个内存是这进程创建之初从系统分配的，它所有创建的变量都会存储在这一片内存环境当中一个是它的上下文环境我们知道进程是运行在操作系统的，那么对于程序来说，它的运行依赖操作系统分配给它的资源，操作系统的一些状态。在操作系统中可以运行多个进程的，对于一个进程来说，它可以创建自己的子进程，那么当我们在一个进程中创建出若干个子进程的时候那么可以看到如图，子进程和父进程一样，拥有自己的内存空间和上下文环境clipboard.png二、Swoole进程结构Swoole的高效不仅仅于底层使用c编写，他的进程结构模型也使其可以高效的处理业务，我们想要深入学习，并且在实际的场景当中使用必须了解，下面我们先看一下结构图：clipboard.png首先先介绍下swoole的这几种进程分别是干什么的：从这些层级的名字，我们先大概说一下，下面这些层级分别是干什么的，做一个详细的说明。Master进程：主进程Manger进程：管理进程Worker进程：工作进程Task进程：异步任务工作进程1、Master进程第一层，Master进程，这个是swoole的主进程,这个进程是用于处理swoole的核心事件驱动的，那么在这个进程当中可以看到它拥有一个MainReactor[线程]以及若干个Reactor[线程]，swoole所有对于事件的监听都会在这些线程中实现，比如来自客户端的连接，信号处理等。clipboard.png每一个线程都有自己的用途，下面多每个线程有一个了解MainReactor（主线程）主线程会负责监听server socket，如果有新的连接accept，主线程会评估每个Reactor线程的连接数量。将此连接分配给连接数最少的reactor线程，做一个负载均衡。Reactor线程组Reactor线程负责维护客户端机器的TCP连接、处理网络IO、收发数据完全是异步非阻塞的模式。swoole的主线程在Accept新的连接后，会将这个连接分配给一个固定的Reactor线程，在socket可读时读取数据，并进行协议解析，将请求投递到Worker进程。在socket可写时将数据发送给TCP客户端。心跳包检测线程（HeartbeatCheck）Swoole配置了心跳检测之后，心跳包线程会在固定时间内对所有之前在线的连接发送检测数据包UDP收包线程（UdpRecv）接收并且处理客户端udp数据包2、管理进程ManagerSwoole想要实现最好的性能必须创建出多个工作进程帮助处理任务，但Worker进程就必须fork操作，但是fork操作是不安全的，如果没有管理会出现很多的僵尸进程，进而影响服务器性能，同时worker进程被误杀或者由于程序的原因会异常退出，为了保证服务的稳定性，需要重新创建worker进程。Swoole在运行中会创建一个单独的管理进程，所有的worker进程和task进程都是从管理进程Fork出来的。管理进程会监视所有子进程的退出事件，当worker进程发生致命错误或者运行生命周期结束时，管理进程会回收此进程，并创建新的进程。换句话也就是说，对于worker、task进程的创建、回收等操作全权有“保姆”Manager进程进行管理。再来一张图梳理下Manager进程和Worker/Task进程的关系。clipboard.png3、Worker进程worker 进程属于swoole的主逻辑进程，用户处理客户端的一系列请求，接受由Reactor线程投递的请求数据包，并执行PHP回调函数处理数据生成响应数据并发给Reactor线程，由Reactor线程发送给TCP客户端可以是异步非阻塞模式，也可以是同步阻塞模式4、Task进程taskWorker进程这一进城是swoole提供的异步工作进程，这些进程主要用于处理一些耗时较长的同步任务，在worker进程当中投递过来。三、进程查看及流程梳理当启动一个Swoole应用时，一共会创建2 + n + m个进程，2为一个Master进程和一个Manager进程，其中n为Worker进程数。m为TaskWorker进程数。默认如果不设置，swoole底层会根据当前机器有多少CPU核数，启动对应数量的Reactor线程和Worker进程。我机器为1核的。Worker为1。所以现在默认我启动了1个Master进程，1个Manager进程，和1个worker进程，TaskWorker没有设置也就是为0，当前server会产生3个进程。在启动了server之后，在命令行查看当前产生的进程clipboard.png这三个进程中，所有进程的根进程，也就是例子中的2123进程，就是所谓的Master进程；而2212进程，则是Manager进程；最后的2321进程，是Worker进程。client跟server的交互1、client请求到达 Main Reactor,Client实际上是与Master进程中的某个Reactor线程发生了连接。2、Main Reactor根据Reactor的情况，将请求注册给对应的Reactor (每个Reactor都有epoll。用来监听客户端的变化) 3、客户端有变化时Reactor将数据交给worker来处理4、worker处理完毕，通过进程间通信(比如管道、共享内存、消息队列)发给对应的reactor。 5、reactor将响应结果发给相应的连接请求处理完成示意图：clipboard.png后续准备本文是在自己学习Swoole接触到的一些知识，在初步整理后发送出来，希望能与大家一起学习，文章不足等问题大家可以一起讨论学习，欢迎骚扰~~。后面准备从网络模型入手更好的理解swoole的实现原理，比较与传统PHP-FPM工作模式的问题，之前出过一篇关于（一）如何实现一个单进程阻塞的网络服务器大家可以先了解下，如何一步步演变为多进程master-worker模型。

如何防止PHP进程异常退出（进程被杀）？ 如何防止PHP进程异常退出（进程被杀）？背景通常，在cli下运行的常驻后台PHP进程，可能异常退出，比如php执行过程中出现的致命错误，或被 kill 命令手动杀死等。如下面的php代码：<?phpwhile(1){$content = fgets(STDIN); if(empty($content)){ sleep(1); } //逻辑处理部分代码省略}?>查错我们使用register_shutdown_function可以跟踪到底是什么错误导致的进程退出。(想更多了解register_shutdown_function，请查看博文 妙用php中的register_shutdown_function和fastcgi_finish_request)加入了错误捕捉代码。如下：<?php$is_end = false;function catch_error(){ global $is_end; $time = date('Y-m-d H:i:s'); $error = error_get_last(); $msg = "$time [error]"; if($is_end){ $msg .= "is_end[yes]"; }else{ $msg .= "is_end[no]"; } if($error){ $msg .= var_export($error,1); } echo $msg."\r\n";}register_shutdown_function("catch_error");?>可是，php当进程再次退出时，在日志中并没有记录任何信息。说明register_shutdown_function方法根本没有执行。是什么导致register_shutdown_function方法没有运行呢？在php的官方文档中又这样一个注释：Shutdown functions will not be executed if the process is killed with a SIGTERM or SIGKILL signal. While you cannot intercept a SIGKILL, you can use pcntl_signal() to install a handler for a SIGTERM which uses exit() to end cleanly.注释的意思是当php进程获得SIGTERM和SIGKILL信号而退出时，是不执行register_shutdown_function方法的。可以使用pcntl_signal()方法来捕获信息，并调用相应的处理方法。好，如何检测是信号导致我们的php进程退出的呢？我们加入如下代码：<?phpdeclare(ticks = 1);function sig_handler($signo){ $time = date('Y-m-d H:i:s'); echo $time." exit signo[{$signo}]\r\n"; exit("");}pcntl_signal(SIGTERM, "sig_handler");pcntl_signal(SIGHUP, "sig_handler");pcntl_signal(SIGINT, "sig_handler");pcntl_signal(SIGQUIT, "sig_handler");pcntl_signal(SIGILL, "sig_handler");pcntl_signal(SIGPIPE, "sig_handler");pcntl_signal(SIGALRM, "sig_handler");?>过一段时间，发现php进程退出了，日志中出现了如下日志信息：2014-11-23 18:30:06 exit signo[14]2014-11-23 18:30:06 [error]is_end[no]看来是sigalarm信号导致php进程退出了。这个信号是可以捕获和处理的。kill 命令会发出sigalarm信号。最终的代码如下：<?phpdeclare(ticks = 1);$is_end = false;function catch_error(){ global $is_end; $time = date('Y-m-d H:i:s'); $error = error_get_last(); $msg = "$time [error]"; if($is_end){ $msg .= "is_end[yes]"; }else{ $msg .= "is_end[no]"; } if($error){ $msg .= var_export($error,1); } echo $msg."\r\n";}register_shutdown_function("catch_error");function sig_handler($signo){ $time = date('Y-m-d H:i:s'); if($signo == 14){ //忽略alarm信号 echo $time." ignore alarm signo[{$signo}]\r\n"; }else{ echo $time." exit signo[{$signo}]\r\n"; exit(""); }}pcntl_signal(SIGTERM, "sig_handler");pcntl_signal(SIGHUP, "sig_handler");pcntl_signal(SIGINT, "sig_handler");pcntl_signal(SIGQUIT, "sig_handler");pcntl_signal(SIGILL, "sig_handler");pcntl_signal(SIGPIPE, "sig_handler");pcntl_signal(SIGALRM, "sig_handler");while(1){$content = fgets(STDIN); if(empty($content)){ sleep(1); } //逻辑处理部分代码省略}$is_end = true;?>这时再kill 进程，在日志中就发现了alarm相关的日志，但是php进程依然在。PS：以上代码如果用kill -9命令杀死（SIGKILL信号），还是会退出的。也就是说SIGKILL信号是无法捕获的。参考http://blogread.cn/it/article/7256?f=wb_blogread

浅谈 Node.js 和 PHP 进程管理 浅谈 Node.js 和 PHP 进程管理众所周知，PHP 占据了服务端编程语言的半壁江山，正如汪峰在音乐圈的地位一般。随着 Node.js 逐渐走上服务端编程的舞台，关于 PHP 和 Node.js 孰优孰劣的争论也不曾间断。垄断性的市场份额足以佐证 PHP 的优秀。并且 HHVM 虚拟机、PHP 7 的革新，也给 PHP 带来了跨越式的性能突破。然而，当我们为语言层面的性能差异喋喋不休时，却往往忽略了 Web 模型在性能表现中的权重。从 CGI 到 FastCGI早期的 Web 服务，是基于传统的 CGI 协议实现的。每个发送到服务器的请求，都需要经过启动进程、处理请求、结束进程三个步骤，以至于访问量增大时，系统资源（如内存、CPU 等）开销也巨大，导致服务器性能下降甚至服务中断。图 1：简单的 CGI 流程示意在 CGI 协议下，解析器的反复加载是性能低下的主要原因。如果让解析器进程长驻内存，那么它只需启动一次，就可以一直执行着，不必每次都重新 fork 进程，这就有了后来的 FastCGI 协议。如果 FastCGI 仅仅做到这样，那么和 Node.js 单进程单线程的模型是基本一致的：Node.js 进程启动后保持持续运行，所有的请求都由这个进程接收和处理，当某个请求引起未知错误时，才可能致使进程退出。事实上 FastCGI 并没有那么简单，为了保证服务的稳定性，他被设计成了多进程调度的模式：图 2：Nginx + FastCGI 执行过程这个过程同样可以描述为三个步骤：首先，初始化 FastCGI 进程管理器，并启动多个 CGI 解释器子进程；接着，当请求到达 Web 服务器时，进程管理器选择并连接一个子进程，将环境变量和标准输入发送给它，处理完成后将标准输出和错误信息返还给 Web 服务器；最终，子进程关闭连接，继续等待下一个请求的到来；从 child_process 到 cluster我们回过头来看看 Node.js 的进程管理方式。原生 Node.js 的单进程单线程模型是一个极易被喷的槽点。这种机制也决定了 Node.js 天生只支持单核 CPU，无法有效地利用多核资源，一旦进程崩溃，还会导致整个 Web 服务的土崩瓦解。图 3：简单的 Node.js 的请求模型和 CGI 一样，单一进程始终面临着可靠性低、稳定性差的问题，当真正服务于生产环境时，这样的弱点相当致命。如果代码本身足够健壮，倒可以在一定程度上避免出错，但同时也对测试工作提出了更高要求。现实中我们无法避免代码 100% 不出纰漏，有些东西容易编写测试用例，有些东西却只能依靠人肉目测。所幸 Node.js 提供了 child_process 模块，通过简单 fork 即可随意创建出子进程。如果为每个 CPU 分别指派一个子进程，多核利用就完美实现了。于此同时，由于child_process 模块本身继承自 EventEmitter 这个基础类，事件驱动使得进程间的通信非常高效。图 4：简单的 Node.js master-worker 模型（扒的淘杰老湿的图）为了简化庞杂的父子进程模型实现，Node.js 紧接着又封装了 cluster 模块，不论是负载均衡、资源回收，还是进程守护，它都会像保姆一样帮你默默地搞定一切。具体技术细节可以参考淘杰老湿的《当我们谈论 cluster 时我们在谈论什么(上)》和《当我们谈论 cluster 时我们在谈论什么(下)》，里面有所有关于 cluster 方案的推演和实现，这里不再赘述。在 Node.js 里，要让应用跑在多核集群上，只需寥寥几行代码就万事大吉了：var cluster = require('cluster');var os = require('os');if (cluster.isMaster) {for (var i = 0, n = os.cpus().length; i < n; i ++) { cluster.fork(); }} else {// 启动应用...}那么反观 FastCGI 协议，它又是如何处理这种模型的呢？PHP-FPM 的天生缺陷PHP-FPM 是 PHP 针对 FastCGI 协议的具体实现，也是 PHP 在多种服务器端应用编程端口（SAPI：cgi、fast-cgi、cli、isapi、apache）里使用最普遍、性能最佳的一款进程管理器。它同样实现了类似 Node.js 的父子进程管理模型，确保了 Web 服务的可靠性和高性能。PHP-FPM 这种模型是非常典型的多进程同步模型，意味着一个请求对应一个进程线程，并且 IO 是同步阻塞的。所以尽管 PHP-FPM 维护着独立的 CGI 进程池、系统也可以很轻松的管理进程的生命周期，但注定无法像 Node.js 那样，一个进程就可以承担巨大的请求压力。受制于服务器的硬件设施，PHP-FPM 需要指定合理的 php-fpm.conf 配置：pm.max_children # 子进程最大数pm.start_servers # 启动时的子进程数pm.min_spare_servers # 最小空闲进程数，空闲进程不够时自动补充pm.max_spare_servers # 最大空闲进程数，空闲进程超过时自动清理pm.max_requests = 1000 # 子进程请求数阈值，超过后自动回收和 JS 不一样的是，PHP 进程本身并不存在内存泄露的问题，每个进程完成请求处理后会回收内存，但是并不会释放给操作系统，这就导致大量内存被 PHP-FPM 占用而无法释放，请求量升高时性能骤降。所以 PHP-FPM 需要控制单个子进程请求次数的阈值。很多人会误以为 max_requests 控制了进程的并发连接数，实际上 PHP-FPM 模式下的进程是单一线程的，请求无法并发。这个参数的真正意义是提供请求计数器的功能，超过阈值数目后自动回收，缓解内存压力。或许你已经发现了问题的关键：尽管 PHP-FPM 架构卓越，但还是卡在单一进程的性能上了。Node.js 天生没有这个问题，而 PHP-FPM 却无法保证，它的稳定性受制于硬件设施和配置文件的契合度，以及 Web 服务器（通常是 Nginx）对 PHP-FPM 服务的负载调度能力。ReactPHP，事件驱动，异步执行，非阻塞 IO对 PHP 7 的狂热掩盖了 Node.js 带来的猛烈冲击。当大家还沉醉在如何选择 HHVM 还是 PHP 7 的时候，ReactPHP 也在茁壮成长，它彻彻底底抛弃了 nginx + php-fpm 的传统架构，转而模仿并接纳了 Node.js 的事件驱动和非阻塞 IO 模型，甚至连副标题，都起得一毛一样：Event-driven, non-blocking I/O with PHP.鉴于大家都比较了解 Node.js，对 ReactPHP 的原理就不再赘述了，我们可以认为它就是个 PHP 版的 Node.js。拿它和传统架构（Nginx + PHP-FPM，公平起见，PHP-FPM 只开一个进程）去做对比，结果是这样的：图 5：输出“Hello World”时的 QPS 曲线图 6：查询 SQL 时的 QPS 曲线我们可以看到，当事件驱动、异步执行、非阻塞 IO 被移植嫁接到 PHP 上后，即便没了 PHP-FPM 支撑，QPS 曲线依然不错，在 IO 密集型的场景下，性能甚至得到了成倍成倍的提升。事件和异步回调机制真是太赞了，它巧妙地将大规模并发、大吞吐量时的拥堵化解为一个异步事件队列，然后挨个解决阻塞（如文件读取，数据库查询等）。针对单进程模型的吐槽，或许有些偏激。不过显而易见的事实是，单进程模型的可靠性，在 Web 服务器和进程管理器层面是有很大的优化空间的，而高并发的处理能力取决于语言特性，说白了就是事件和异步的支持。这两点想必是让 Node.js 天生骄傲的事情，但在 PHP 里没有得到原生支持，只能通过模拟步进操作的方式来支持类似 Node.js 的事件机制，所以 ReactPHP 其实也并没有想象中那么完美。结束语大部分时候，当我们比较语言优劣，容易局限在语言本身，而忽视了配套的一些关键因素。就拿 PHP 来说，这两年听到了太多关于即时编译器（JIT）、opcode 缓存、抽象语法树（AST）、HHVM 等等之类的话题。当这些优化逐步完备，语言层面的问题，早已不再是 Web 性能的短板了。如果实在不行，我们还可以把复杂任务交给 C 和 C++，以 Node.js addon 或者 PHP 扩展的形式，轻轻松松就搞定了。都说 PHP 是“世界上最好的语言”，既然如此，也是时候学习下 Node.js 事件驱动和异步回调，考虑考虑如何对 PHP-FPM 进行大刀阔斧的革新。毕竟不管是 Node.js 还是 PHP，我们所擅长的地方，终将还是 Web，高性能的 Web。相关资料FastCGI Process Manager (FPM)ReactPHP - Event-driven, non-blocking I/O with PHP.ReactPHP - PHP 版的 Node.js当我们谈论 cluster 时我们在谈论什么(上)当我们谈论 cluster 时我们在谈论什么(下)