进程的基本知识
什么是进程，所谓进程其实就是操作系统中一个正在运行的程序，我们在一个终端当中，通过php，运行一个php文件，这个时候就相当于我们创建了一个进程，这个进程会在系统中驻存，申请属于它自己的内存空间系统资源并且运行相应的程序
对于一个进程来说，它的核心内容分为两个部分，一个是它的内存，这个内存是这进程创建之初从系统分配的，它所有创建的变量都会存储在这一片内存环境当中
一个是它的上下文环境我们知道进程是运行在操作系统的，那么对于程序来说，它的运行依赖操作系统分配给它的资源，操作系统的一些状态。
在操作系统中可以运行多个进程的，对于一个进程来说，它可以创建自己的子进程，那么当我们在一个进程中创建出若干个子进程的时候那么可以看到如图，子进程和父进程一样，拥有自己的内存空间和上下文环境
Swoole进程结构
首先先介绍下swoole的这几种进程分别是干什么的
从这些层级的名字，我们先大概说一下，下面这些层级分别是干什么的，做一个详细的说明。
- 1、Master进程：主进程
- 2、Manger进程：管理进程
- 3、Worker进程：工作进程
- 4、Task进程：异步任务工作进程
Master进程
第一层，Master进程，这个是swoole的主进程,这个进程是用于处理swoole的核心事件驱动的，那么在这个进程当中可以看到它拥有一个MainReactor[线程]以及若干个Reactor[线程]，swoole所有对于事件的监听都会在这些线程中实现，比如来自客户端的连接，信号处理等。
每一个线程都有自己的用途，下面多每个线程有一个了解
MainReactor（主线程）
主线程会负责监听server socket，如果有新的连接accept，主线程会评估每个Reactor线程的连接数量。将此连接分配给连接数最少的reactor线程，做一个负载均衡。
Reactor线程组
Reactor线程负责维护客户端机器的TCP连接、处理网络IO、收发数据完全是异步非阻塞的模式。
swoole的主线程在Accept新的连接后，会将这个连接分配给一个固定的Reactor线程，在socket可读时读取数据，并进行协议解析，将请求投递到Worker进程。在socket可写时将数据发送给TCP客户端。
心跳包检测线程（HeartbeatCheck）
Swoole配置了心跳检测之后，心跳包线程会在固定时间内对所有之前在线的连接发送检测数据包
UDP收包线程（UdpRecv）
接收并且处理客户端udp数据包
管理进程Manager
Swoole想要实现最好的性能必须创建出多个工作进程帮助处理任务，但Worker进程就必须fork操作，但是fork操作是不安全的，如果没有管理会出现很多的僵尸进程，进而影响服务器性能，同时worker进程被误杀或者由于程序的原因会异常退出，为了保证服务的稳定性，需要重新创建worker进程。
Swoole在运行中会创建一个单独的管理进程，所有的worker进程和task进程都是从管理进程Fork出来的。管理进程会监视所有子进程的退出事件，当worker进程发生致命错误或者运行生命周期结束时，管理进程会回收此进程，并创建新的进程。换句话也就是说，对于worker、task进程的创建、回收等操作全权有“保姆”Manager进程进行管理。
再来一张图梳理下Manager进程和Worker/Task进程的关系。
Worker进程
worker 进程属于swoole的主逻辑进程，用户处理客户端的一系列请求，接受由Reactor线程投递的请求数据包，并执行PHP回调函数处理数据生成响应数据并发给Reactor线程，由Reactor线程发送给TCP客户端可以是异步非阻塞模式，也可以是同步阻塞模式
Task进程
taskWorker进程这一进城是swoole提供的异步工作进程，这些进程主要用于处理一些耗时较长的同步任务，在worker进程当中投递过来。
swoole进程查看及流程梳理
进程查看
当启动一个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之后，在命令行查看当前产生的进程
这三个进程中，所有进程的根进程，也就是例子中的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将响应结果发给相应的连接请求处理完成
示意图：
进程的绑定事件
大概了解下，后面会相应的触发这些事件
Master进程内的回调函数
1onStart Server启动在主进程的主线程回调此函数
2onShutdown 此事件在Server正常结束时发生
Manager进程内的回调函数
1onManagerStart 当管理进程启动时调用它
2onManagerStop 当管理进程结束时调用它
3onWorkerError 当worker/task_worker进程发生异常后会在Manager进程内回调此函数
Worker进程内的回调函数
1onWorkerStart 此事件在Worker进程/Task进程启动时发生
2onWorkerStop 此事件在worker进程终止时发生。
3onConnect 有新的连接进入时，在worker进程中回调
4onClose TCP客户端连接关闭后，在worker进程中回调此函数
5onReceive 接收到数据时回调此函数，发生在worker进程中
6onPacket 接收到UDP数据包时回调此函数，发生在worker进程中
7onFinish 当worker进程投递的任务在task_worker中完成时，task进程会通过finish()方法将任务处理的结果发送给worker进程。
8onWorkerExit 仅在开启reload_async特性后有效。异步重启特性
9onPipeMessage 当工作进程收到由 sendMessage 发送的管道消息时会触发事件
Task进程内的回调函数
1onTask 在task_worker进程内被调用。worker进程可以使用swoole_server_task函数向task_worker进程投递新的任务
2onWorkerStart 此事件在Worker进程/Task进程启动时发生
3onPipeMessage 当工作进程收到由 sendMessage 发送的管道消息时会触发事件
简单说明：
- 1、服务器关闭程序终止时最后一次事件是onShutdown。
- 2、服务器启动成功后，onStart/onManagerStart/onWorkerStart会在不同的进程内并发执行，并不是顺序的。
- 3、所有事件回调均在$server->start后发生，start之后写的代码是无效代码。
- 4、onStart/onManagerStart/onWorkerStart 3个事件的执行顺序是不确定的
- Swoole的Reactor、Worker、TaskWorker之间可以紧密的结合起来，提供更高级的使用方式。
一个更通俗的比喻，假设Server就是一个工厂，那Reactor就是销售，接受客户订单。而Worker就是工人，当销售接到订单后，Worker去工作生产出客户要的东西。而TaskWorker可以理解为行政人员，可以帮助Worker干些杂事，让Worker专心工作。
网络服务模型
单进程阻塞的网络服务器
如下图所示
说明：
1、创建一个socket，绑定服务器端口（bind），监听端口（listen），在PHP中用stream_socket_server一个函数就能完成上面3个步骤
2、进入while循环，阻塞在accept操作上，等待客户端连接进入。此时程序会进入睡眠状态，直到有新的客户端发起connect到服务器，操作系统会唤醒此进程。accept函数返回客户端连接的socket
3、利用fread读取客户端socket当中的数据收到数据后服务器程序进行处理然后使用fwrite向客户端发送响应。长连接的服务会持续与客户端交互，而短连接服务一般收到响应就会close。
缺点： 1、一次只能处理一个连接，不支持多个连接同时处理
预派生子进程模式
说明：
前面流程一致就不补充了
程序启动后就会创建N个进程。每个子进程进入Accept，等待新的连接进入。当客户端连接到服务器时，其中一个子进程会被唤醒，开始处理客户端请求，并且不再接受新的TCP连接。当此连接关闭时，子进程会释放，重新进入Accept，参与处理新的连接。
这个模型的优势是完全可以复用进程，不需要太多的上下文切换，比如php-fpm基于此模型的。
缺点：
1、这种模型严重依赖进程的数量解决并发问题，一个客户端连接就需要占用一个进程，工作进程的数量有多少，并发处理能力就有多少。操作系统可以创建的进程数量是有限的。
例如：即时聊天程序，一台服务器可能要维持数十万的连接，那么就要启动数十万的进程来维持。这显然不可能
基于上面的模式我们发现我们只能通过每次（accept）处理单个请求，没办法一次性处理多个请求？
单进程阻塞复用的网络服务器
如下图所示
说明：
- 服务监听流程如上
- 1、保存所有的socket,通过select系统调用，监听socket描述符的可读事件
- 2、Select会在内核空间监听一旦发现socket可读，会从内核空间传递至用户空间，在用户空间通过逻辑判断是服务端socket可读，还是客户端的socket可读
- 3、如果是服务端的socket可读，说明有新的客户端建立，将socket保留到监听数组当中
- 4、如果是客户端的socket可读，说明当前已经可以去读取客户端发送过来的内容了，读取内容，然后响应给客户端
缺点：
- 1、select模式本身的缺点（1、循环遍历处理事件、2、内核空间传递数据的消耗）
- 2、单进程对于大量任务处理乏力
多进程master-worker模型
1、master进程，负责处理配置文件读取，启动，终止和维护工作(worker)进程数，当woker进程退出后（异常情况下），会自动重新启动新的woker
2、worker进程的主要任务是完成具体的任务逻辑，启动端口监听，接收客户端请求、使用epoll接收请求，执行业务逻辑然后关闭连接。 其中对于进程重新启动我们需要通过发送信号来实现
IO复用/EventLoop
IO复用是什么？
IO多路复用是指内核一旦发现进程指定的一个或者多个IO条件准备读取，它就通知该进程，目前支持I/O多路复用有 select，poll，epoll，I/O多路复用就是通过一种机制，一个进程可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作
Select跟poll
Select介绍： 监视并等待多个文件描述符的属性变化（可读、可写或错误异常）。select函数监视的文件描述符分 3 类，分别是writefds、readfds、和 exceptfds。调用后 select会阻塞，直到有描述符就绪（有数据可读、可写、或者有错误异常），或者超时（ timeout 指定等待时间），函数才返回。当 select()函数返回后，可以通过遍历 fdset，来找到就绪的描述符，并且描述符最大不能超过1024
poll 介绍： poll的机制与select类似，与select在本质上没有多大差别，管理多个描述符也是进行轮询，根据描述符的状态进行处理，但是poll没有最大文件描述符数量的限制。poll和select同样存在一个缺点就是，包含大量文件描述符的数组被整体复制于用户态和内核的地址空间之间，而不论这些文件描述符是否就绪，它的开销随着文件描述符数量的增加而线性增大。
问题： select/poll问题很明显，它们需要循环检测连接是否有事件。如果服务器有上百万个连接，在某一时间只有一个连接向服务器发送了数据，select/poll需要做循环100万次，其中只有1次是命中的，剩下的99万9999次都是无效的，白白浪费了CPU资源。
epoll: epoll是在2.6内核中提出的，是之前的select和poll的增强版本。相对于select和poll来说，epoll更加灵活，没有描述符限制,无需轮询。epoll使用一个文件描述符管理多个描述符，将用户关系的文件描述符的事件存放到内核的一个事件表中。 简单点来说就是当连接有I/O流事件产生的时候，epoll就会去告诉进程哪个连接有I/O流事件产生，然后进程就去处理这个事件。
高效的事件处理模式Reactor 模式 Reactor模型，Reactor顾名思义就是反应堆的意思，它本身不处理任何数据收发。只是可以监视一个socket句柄的事件变化。
- 1） 主进程/线程往epoll内核亊件中注册socket上的读就绪亊件。
- 2） 主进程/线程调用epoll_wait等待socket上有数据可读。
- 3） 当socket上有数据可读时，epoll_wait通知主进程/线程。主进程/线程则将socket可读事件放人请求队列。
- 4） 睡眠在请求队列上的某个工作线程被唤醒，它从socket读取数据，并处理客户请求， 然后往epoll内核事件表中注册该socket上的写就绪事件。
- 5） 主线程调用epoll_wait等待socket可写。
- 6） 当socket可写时，epoll_wait通知主进程/线程将socket可写亊件放人清求队列。
- 7） 睡眠在请求队列上的某个工作线程被唤醒，它往socket上写人服务器处理客户淸求
不过我们今天要实现的是属于一种变种，是类似于nginx采用的Reactor 多进程的模式，具体差异表现为主进程中仅仅创建了监听，并没有创建 mainReactor 来“accept”连接，而是由子进程的 Reactor 来“accept”连接，通过负载均衡，一次只有一个子进程进行“accept”，子进程“accept”新连接后就放到自己的 Reactor中进行处理，不会再分配给其他子进程
进程相关
关于进程相关的概念之前都已经解释了，这里着重关注下，进程的复制发送点，创建进程可以使用fork函数
fork函数
fork函数将创建调用的进程副本，并非根据完全不同的程序创建进程，而是复制正在运行的、调用fork函数的进程，但因为通过同一个进程、复制相同的内存空间，之后需要根据返回值加以区分：
-
- 父进程空间：fork函数会返回子进程id
-
- 子进程空间：fork函数返回0
-
- 如果小于0，说明进程创建失败，下面了解下fork创建进程的过程此处可参考（tcp/ip）网络编程168页
处理僵尸进程
对于多进程程序而言，父进程一般需要跟踪子进程的退出状态。因此，当子进程结束运行时，内核不会立即释放该进程的进程表表项，以满足父进程后续对该子进程退出信息的查询 (如果父进程还在运行)。在子进程结束运行之后，父进程读取其退出状态之前，我们称该子进程处于僵尸态，另外一种使子进程进人僵尸状态是：父进程结束或者异常终止，而子进程继续运行。
由此可见，无论哪种情况，如果父进程没有正确地处理子进程的返冋信息，子进程都将停留在僵尸态，并占据内核资源.这是绝对不能容许的，毕竞内核资源有限，所以我们需要做的就是在父进程中调用wait函数等待查询子进程的信息，回收子进程
信号处理
信号是由用户、系统或者进程发送给目标进程的信息，以通知目标进程某个状态的改变 或系统异常。Linux信号可由如下条件产生：
- 对于前台进程，用户可以通过输人特殊的终端字符来给它发送信号。比如输入Ctrl+C 通常会给进程发送一个中断信号。
- 系统异常。比如浮点异常和非法内存段访问。
- 系统状态变化。比如alarm定时器到期将引起SIGALRM信号。
- 运行kill命令或调用kill函数。
服务器程序必须处理(或至少忽略)一些常见的信号”，以免异常终止。
一部分信号，可通过kill -l查看所有：
1SIGHUP 终止进程 终端线路挂断
2SIGINT 终止进程 中断进程
3SIGKILL 终止进程 杀死进程
4SIGPIPE 终止进程 向一个没有读进程的管道写数据
5SIGALARM 终止进程 计时器到时
6SIGTERM 终止进程 软件终止信号
7SIGSTOP 停止进程 非终端来的停止信号
8SIGTSTP 停止进程 终端来的停止信号
9SIGCONT 忽略信号 继续执行一个停止的进程
10SIGURG 忽略信号 I/O紧急信号
11SIGIO 忽略信号 描述符上可以进行I/O
12SIGPROF 终止进程 统计分布图用计时器到时
13SIGUSR1 终止进程 用户定义信号1
14SIGUSR2 终止进程 用户定义信号2
15SIGVTALRM 终止进程 虚拟计时器到时
守护进程、信号和平滑重启
守护进程
我们现在开启的server，不管我们程序写的多么精彩，都没有办法把项目应用到实际业务中，只要把运行server的终端关闭之后，server也就不复存在了。
守护进程（daemon）就是一种长期生存的进程，它不受终端的控制，可以在后台运行。其实我们之前也有了解，比如说nginx，fpm等一般都是作为守护进程在后台提供服务。
Swoole实现守护进程
启用守护进程后，server内所有的标准输出都会被丢弃，这样的话我们也就无法跟踪进程在运行过程中是否异常之类的错误信息了。一般会配合log_file我们可以指定日志路径，这样swoole在运行时就会把所有的标准输出统统记载到该文件内。
swoole运行模式及热重启
Swoole之所以性能卓越，是因为Swoole减少了每一次请求加载PHP文件以及初始化的开销。但是这种优势也导致开发者无法像过去一样，修改PHP文件，重新请求，就能获取到新代码的运行结果（具体看另外的课程文档）。如果需要新代码开始执行，往往需要先关闭服务器然后重启，这样才能使得新文件被加载进内存运行，这样很明显不能满足开发者的需求。幸运的是，Swoole 提供了这样的功能。
在swoole中，我们可以向主进程发送各种不同的信号，主进程根据接收到的信号类型做出不同的处理。比如下面这几个
1、kill -SIGTERM|-15 master_pid 终止Swoole程序,一种优雅的终止信号，会待进程执行完当前程序之后中断，而不是直接干掉进程
2、kill -USR1|-10 master_pid 重启所有的Worker进程
3、kill -USR2|-12 master_pid 重启所有的Task Worker进程
当USR1信号被发送给Master进程后，Master进程会将同样的信号通过Manager进程转发Worker进程，收到此信号的Worker进程会在处理完正在执行的逻辑之后，释放进程内存，关闭自己，然后由Manager进程重启一个新的Worker进程。新的Worker进程会占用新的内存空间。
具体场景：
如果是上线的项目，一台繁忙的后端服务器随时都在处理请求，如果管理员通过kill进程方式来终止/重启服务器程序，可能导致刚好代码执行到一半终止。
这种情况下会产生数据的不一致。如交易系统中，支付逻辑的下一段是发货，假设在支付逻辑之后进程被终止了。会导致用户支付了货币，但并没有发货，后果非常严重。
如何解决？
这个时候我们需要考虑如何平滑重启server的问题了。所谓的平滑重启，也叫“热重启”，就是在不影响用户的情况下重启服务，更新内存中已经加载的php程序代码，从而达到对业务逻辑的更新。
swoole为我们提供了平滑重启机制，我们只需要向swoole_server的主进程发送特定的信号，即可完成对server的重启。
注意事项：
- 1、更新仅仅只是针对worker进程，也就是写在master进程跟manger进程当中更新代码并不生效，也就是说只有在onWorkerStart回调之后加载的文件，重启才有意义。在Worker进程启动之前就已经加载到内存中的文件，如果想让它重新生效，只能关闭server再重启。
- 2、直接写在worker代码当中的逻辑是不会生效的，就算发送了信号也不会，需要通过include方式引入相关的业务逻辑代码才会生效
实际操作
1、首先，我们需要在程序中注册自动加载函数，通过这些自动加载函数实现逻辑文件的更新。
2、其次，我们需要保存服务的Master进程的进程号在目录下创建一个server.pid文件来保存，并在需要重新加载新文件的时候，向Master进程发送USR1信号。当Worker进程重启后，之前加载过的文件就从内存中移除，下一次请求时就会重新加载新的文件。
注意：
1、OnWorkerStart之后加载的代码都在各自进程中，OnWorkerStart之前加载的代码属于共享内存。
2、可以将公用的，不易变的php文件放置到onWorkerStart之前。这样虽然不能重载入代码，但所有worker是共享的，不需要额外的内存来保存这些数据。onWorkerStart之后的代码每个worker都需要在内存中保存一份