Swoole.001.手撸网络服务器模型

Swoole进程结构

Master进程: 主进程
Manger进程: 管理进程
Worker进程: 工作进程
Task进程: 异步任务工作进程

github: https://github.com/masterzcw/swoole/tree/master/swoole/server

Master进程

第一层, Master进程, 这个是swoole的主进程,这个进程是用于处理swoole的核心事件驱动的, 那么在这个进程当中可以看到它拥有一个MainReactor[线程]以及若干个Reactor[线程], swoole所有对于事件的监听都会在这些线程中实现, 比如来自客户端的连接, 信号处理等.
1.1 MainReactor(主线程)
主线程会负责监听server socket, 如果有新的连接accept, 主线程会评估每个Reactor线程的连接数量. 将此连接分配给连接数最少的reactor线程, 做一个负载均衡.
1.2 、Reactor线程组
Reactor线程负责维护客户端机器的TCP连接、处理网络IO、收发数据完全是异步非阻塞的模式.
swoole的主线程在Accept新的连接后, 会将这个连接分配给一个固定的Reactor线程, 在socket可读时读取数据, 并进行协议解析, 将请求投递到Worker进程. 在socket可写时将数据发送给TCP客户端.
1.3、心跳包检测线程(HeartbeatCheck)
Swoole配置了心跳检测之后, 心跳包线程会在固定时间内对所有之前在线的连接
发送检测数据包
1.4、UDP收包线程(UdpRecv)
接收并且处理客户端udp数据包

管理进程Manager

Swoole想要实现最好的性能必须创建出多个工作进程帮助处理任务, 但Worker进程就必须fork操作, 但是fork操作是不安全的, 如果没有管理会出现很多的僵尸进程, 进而影响服务器性能, 同时worker进程被误杀或者由于程序的原因会异常退出, 为了保证服务的稳定性, 需要重新创建worker进程.
Swoole在运行中会创建一个单独的管理进程, 所有的worker进程和task进程都是从管理进程Fork出来的. 管理进程会监视所有子进程的退出事件, 当worker进程发生致命错误或者运行生命周期结束时, 管理进程会回收此进程, 并创建新的进程. 换句话也就是说, 对于worker、task进程的创建、回收等操作全权有"保姆"Manager进程进行管理.

Worker进程

worker 进程属于swoole的主逻辑进程, 用户处理客户端的一系列请求, 接受由Reactor线程投递的请求数据包, 并执行PHP回调函数处理数据生成响应数据并发给Reactor线程, 由Reactor线程发送给TCP客户端可以是异步非阻塞模式, 也可以是同步阻塞模式

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之后, 在命令行查看当前产生的进程
$ pstree -ap|grep packServer.php
-php,11046 swoole/packServer.php |-php,11047 swoole/packServer.php |-php,11049 swoole/packServer.php
11046 是master进程
11047 是Manager进程
11049 是Worker进程

client跟server的交互

client请求到达 Main Reactor,Client实际上是与Master进程中的某个Reactor线程发生了连接.
Main Reactor根据Reactor的情况, 将请求注册给对应的Reactor (每个Reactor都有epoll. 用来监听客户端的变化)
客户端有变化时Reactor将数据交给worker来处理
worker处理完毕, 通过进程间通信(比如管道、共享内存、消息队列)发给对应的reactor.
reactor将响应结果发给相应的连接请求处理完成

进程的绑定事件

Master进程内的回调函数
onStart Server启动在主进程的主线程回调此函数
onShutdown 此事件在Server正常结束时发生
Manager进程内的回调函数
onManagerStart 当管理进程启动时调用它
onManagerStop 当管理进程结束时调用它
onWorkerError 当worker/task_worker进程发生异常后会在Manager进程内回调此函数
Worker进程内的回调函数
onWorkerStart 此事件在Worker进程/Task进程启动时发生
onWorkerStop 此事件在worker进程终止时发生.
onConnect 有新的连接进入时, 在worker进程中回调
onClose TCP客户端连接关闭后, 在worker进程中回调此函数
onReceive 接收到数据时回调此函数, 发生在worker进程中
onPacket 接收到UDP数据包时回调此函数, 发生在worker进程中
onFinish 当worker进程投递的任务在task_worker中完成时, task进程会通过finish()方法将任务处理的结果发送给worker进程.
onWorkerExit 仅在开启reload_async特性后有效. 异步重启特性
onPipeMessage 当工作进程收到由 sendMessage 发送的管道消息时会触发事件
Task进程内的回调函数
onTask 在task_worker进程内被调用. worker进程可以使用swoole_server_task函数向task_worker进程投递新的任务
onWorkerStart 此事件在Worker进程/Task进程启动时发生
onPipeMessage 当工作进程收到由 sendMessage 发送的管道消息时会触发事件
其他的说明

1. 服务器关闭程序终止时最后一次事件是onShutdown.
2. 服务器启动成功后, onStart/onManagerStart/onWorkerStart会在不同的进程内并发执
   行, 并不是顺序的.
3. 所有事件回调均在$server->start后发生, start之后写的代码是无效代码.
4. onStart/onManagerStart/onWorkerStart 3个事件的执行顺序是不确定的

网络服务器演进

单进程阻塞的网络服务器
socket_create -> socket_bind -> socket_listen -> socket_accept -> socket_recv -> 逻辑处理 ->socket_close
问题点: 一次只能处理一个连接, 不支持多个连接同时处理
预派生子进程模式
socket_create -> socket_bind -> socket_listen -> socket_set_nonblock -> pcntl_fork -> pcntl_wait
子进程 -> socket_accept -> socket_recv -> 逻辑处理 ->socket_close
问题点:
1. 这种模型严重依赖进程的数量解决并发问题, 一个客户端连接就需要占用一个进程, 工作进程的数量有多少, 并发处理能力就有多少. 操作系统可以创建的进程数量是有限的.
2. 操作系统生成一个子进程需要进行内存复制等操作, 在资源和时间上会产生一定的开销；当有大量请求时, 会导致系统性能下降；
单进程非阻塞复用的网络服务器
socket_create -> socket_bind -> socket_listen -> socket_set_nonblock -> select/epoll -> socket_accept -> socket_recv -> 逻辑处理 ->socket_close

• 保存所有的socket,通过select模型, 监听socket描述符的可读事件
• Select会在内核空间监听一旦发现socket可读, 会从内核空间传递至用户空间, 在用户空间通过逻辑判断是服务端socket可读, 还是客户端的socket可读
• 如果是服务端的socket可读, 说明有新的客户端建立, 将socket保留到监听数组当中
• 如果是客户端的socket可读, 说明当前已经可以去读取客户端发送过来的内容了, 读取内容, 然后响应给客户端.
  问题点:

• select模式本身的缺点(1、循环遍历处理事件、2、内核空间传递数据的消耗)
  

• 单进程对于大量任务处理乏力
  多进程master-worker模型
  …

IO复用/EventLoop

IO复用
是指内核一旦发现进程指定的一个或者多个IO条件准备读取, 它就通知该进程, 目前支持I/O多路复用的模式有 select, poll, epoll. I/O多路复用就是通过一种机制, 一个进程可以监视多个描述符, 一旦某个描述符就绪(一般是读就绪或者写就绪), 能够通知程序进行相应的读写操作.
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流事件产生, 然后进程就去处理这个进程.
这里可以多加一个选择nginx的原因, 因为Nginx是基于epoll的异步非阻塞的服务器程序. 自然, Nginx能够轻松处理百万级的并发连接, 也就无可厚非了.

守护进程、信号和平滑重启

守护进程

我们现在开启的server, 不管我们程序写的多么精彩, 都没有办法把项目应用到实际业务中, 只要把运行server的终端关闭之后, server也就不复存在了.
守护进程(daemon)就是一种长期生存的进程, 它不受终端的控制, 可以在后台运行. 其实我们之前也有了解, 比如说nginx, fpm等一般都是作为守护进程在后台提供服务.

swoole实现守护进程

‘daemonize’=>true, // 启用守护进程
‘log_file’=>DIR.’/server.log’ // 日志文件
启用守护进程后, server内所有的标准输出都会被丢弃, 这样的话我们也就无法跟踪进程在运行过程中是否异常之类的错误信息了. 一般会配合log_file我们可以指定日志路径, 这样swoole在运行时就会把所有的标准输出统统记载到该文件内.

swoole运行模式及热重启

Swoole之所以性能卓越, 是因为Swoole减少了每一次请求加载PHP文件以及初始化的开销. 但是这种优势也导致开发者无法像过去一样, 修改PHP文件, 重新请求, 就能获取到新代码的运行结果(具体看另外的课程文档). 如果需要新代码开始执行, 往往需要先关闭服务器然后重启, 这样才能使得新文件被加载进内存运行, 这样很明显不能满足开发者的需求. 幸运的是, Swoole 提供了这样的功能.
具体场景
如果是上线的项目, 一台繁忙的后端服务器随时都在处理请求, 如果管理员通过kill进程方式来终止/重启服务器程序, 可能导致刚好代码执行到一半终止.
这种情况下会产生数据的不一致. 如交易系统中, 支付逻辑的下一段是发货, 假设在支付逻辑之后进程被终止了. 会导致用户支付了货币, 但并没有发货, 后果非常严重.
如何解决
这个时候我们需要考虑如何平滑重启server的问题了. 所谓的平滑重启, 也叫"热重启", 就是在不影响用户的情况下重启服务, 更新内存中已经加载的php程序代码, 从而达到对业务逻辑的更新.
swoole为我们提供了平滑重启机制, 我们只需要向swoole_server的主进程发送特定的信号, 即可完成对server的重启.
信号
在swoole中, 我们可以向主进程发送各种不同的信号, 主进程根据接收到的信号类型做出不同的处理. 比如下面这几个

• kill -SIGTERM|-15 master_pid 终止Swoole程序,一种优雅的终止信号, 会待进程执行完当前程序之后中断, 而不是直接干掉进程
• kill -USR1|-10 master_pid 重启所有的Worker进程
• kill -USR2|-12 master_pid 重启所有的Task Worker进程
  当USR1信号被发送给Master进程后, Master进程会将同样的信号通过Manager进程转发Worker进程, 收到此信号的Worker进程会在处理完正在执行的逻辑之后, 释放进程内存, 关闭自己, 然后由Manager进程重启一个新的Worker进程. 新的Worker进程会占用新的内存空间.
  注意事项
• 更新仅仅只是针对worker进程, 也就是写在master进程跟manger进程当中更新代码并不生效, 也就是说只有在onWorkerStart回调之后加载的文件, 重启才有意义. 在Worker进程启动之前就已经加载到内存中的文件, 如果想让它重新生效, 只能关闭server再重启.
• 直接写在worker代码当中的逻辑是不会生效的, 就算发送了信号也不会, 需要通过include方式引入相关的业务逻辑代码才会生效
  实际操作
• 首先, 我们需要在程序中注册自动加载函数, 通过这些自动加载函数实现逻辑文件的更新.
• 其次, 我们需要保存服务的Master进程的进程号在目录下创建一个server.pid文件来保存, 并在需要重新加载新文件的时候, 向Master进程发送USR1信号. 当Worker进程重启后, 之前加载过的文件就从内存中移除, 下一次请求时就会重新加载新的文件.
  注 意
• OnWorkerStart之后加载的代码都在各自进程中, OnWorkerStart之前加载的代码属于共享内存.
• 可以将公用的, 不易变的php文件放置到onWorkerStart之前. 这样虽然不能重载入代码, 但所有worker是共享的, 不需要额外的内存来保存这些数据. onWorkerStart之后的代码每个worker都需要在内存中保存一份