这篇文章将为大家详细讲解有关Swoole server的案例分析，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。
一. 基础知识
1.1 Swoole
Swoole是面向生产环境的php异步网络通信引擎, php开发人员可以利用Swoole开发出高性能的server服务。Swoole的server部分, 内容很多, 也涉及很多的知识点, 本文仅对其server进行简单的概述, 具体的实现细节在后续的文章中再进行详细介绍。
推荐（免费）：swoole
1.2 网络编程
1. 网络通信是指在一台(或者多台)机器上启动一个(或者多个)进程, 监听一个(或者多个)端口, 按照某种协议(可以是标准协议http, dns; 也可以是自行定义的协议)与客户端交换信息。
2. 目前的网络编程多是在tcp, udp或者更上层的协议之上进行编程。Swoole的server部分是基于tcp以及udp协议的。
3. 利用udp进行编程较为简单, 本文主要介绍tcp协议之上的网络编程
4. TCP网络编程主要涉及4种事件
●连接建立: 主要是指客户端发起连接(connect)以及服务端接受连接(accept)
●消息到达: 服务端接受到客户端发送的数据,该事件是TCP网络编程最重要的事件,服务端对于该类事件进行处理时, 可以采用阻塞式或者非阻塞式,除此之外, 服务端还需要考虑分包, 应用层缓冲区等问题
●消息发送成功: 发送成功是指应用层将数据成功发送到内核的套接字发送缓冲区中,并不是指客户端成功接受数据。对于低流量的服务而言,数据通常一次性即可发送完,并不需要关心此类事件。如果一次性不能将全部数据发送到内核缓冲区,则需要关心消息是否成功发送(阻塞式编程在系统调用(write, writev, send等)返回后即是发送成功, 非阻塞式编程则需要考虑实际写入的数据是否与预期一致)
●连接断开: 需要考虑客户端断开连接(read返回0)以及服务端断开连接(close, shutdown)
5. tcp建立连接的过程如下图
● 图中, ACK、SYN表示标志位, seq、ack为tcp包的序号以及确认序号
6. tcp断开连接的过程如下图
● 上图考虑的是客户端主动断开连接的情况, 服务端主动断开连接也类似
● 图中, FIN、ACK表示标志位, seq、ack为tcp包的序号以及确认序号
1.3 进程间通信
1. 进程之间的通信有无名管道(pipe), 有名管道(fifo), 信号(signal), 信号量(semaphore), 套接字(socket), 共享内存(shared memory)等方式
2. Swoole中采用unix域套接字(套接字的一种)用于多进程之间的通信(指Swoole内部进程之间)
1.4 socketpair
1. socketpair用于创建一个套接字对, 类似于pipe, 不同的是pipe是单向通信, 双向通信需要创建两次, socketpair调用一次即可实现双向通信, 除此之外, 由于使用的是套接字, 还可以定义数据交换的方式
2. socketpair系统调用
调用成功后sv[0], sv[1]分别存储一个文件描述符
向sv[0]中写入, 可以从sv[1]中读取
向sv[1]中写入, 可以从sv[0]中读取
进程调用socketpair后, fork子进程, 子进程会默认继承sv[0], sv[1]这两个文件描述符, 进而可以实现父子进程间通信。例如, 父进程向sv[0]中写入, 子进程从sv[1]中读取; 子进程向sv[1]中写入, 父进程从sv[0]中读取
1.5 守护进程(daemon)
1. 守护进程是一种特殊的后台进程, 它脱离于终端, 用于周期性的执行某种任务
2. 进程组
每个进程都属于一个进程组
每个进程组都有一个进程组号, 也就是该组组长的进程号(PID)
一个进程只能为自己或者其子进程设置进程组号
3. 会话
一个会话可以包含多个进程组, 这些进程组中最多只能有一个前台进程组(也可以没有), 其余为后台进程组
一个会话最多只能有一个控制终端
用户通过终端登录或者网络登录, 会创建一个新的会话
进程调用系统调用setsid可以创建一个新的会话, 调用setsid的进程不能是某个进程组的组长。setsid调用完成后, 该进程成为这个会话的首进程(领头进程), 同时变成一个新的进程组的组长, 如果该进程之前有控制终端, 该进程与终端的联系也被断开
4. 创建守护进程的方式
fork子进程后, 父进程退出, 子进程执行setsid, 子进程即可成为守护进程。这种方式下, 子进程是会话的领头进程, 可以重新打开终端, 此时可以再次fork, fork产生的子进程无法再打开终端(只有会话的领头进程才能打开终端)。第二次fork并不是必须的, 只是为了防止子进程再次打开终端
linux提供了daemon函数(该函数并不是系统调用, 为库函数)用于创建守护进程
1.6 Swoole tcp server示例
上述代码在cli模式下执行时, 经过词法分析, 语法分析生成opcode, 进而交由zend虚拟机执行
zend虚拟机在执行到$serv->start()时, 启动Swoole server
上述代码中设置的事件回调是在worker进程中执行, 后文会详细介绍Swoole server模型
二. Swoole server
2.1 base模式
1. 说明
base模式采用多进程模型, 这种模型与nginx一致, 每个进程只有一个线程, 主进程负责管理工作进程, 工作进程负责监听端口, 接受连接, 处理请求以及关闭连接
多个进程同时监听端口, 会有惊群问题, linux 3.9之前版本的内核, Swoole没有解决惊群问题
linux 内核3.9及其后续版本提供了新的套接字参数SO_REUSEPORT, 该参数允许多个进程绑定到同一个端口, 内核在接受到新的连接请求时, 会唤醒其中一个进行处理, 内核层面也会做负载均衡, 可以解决上述的惊群问题, Swoole也已经加入了这个参数
base模式下, reactor_number参数并没有实际作用
如果worker进程数设置为1, 则不会fork出worker进程, 主进程直接处理请求, 这种模式适合调试
2. 启动过程
php代码执行到$serv->start()时,主进程进入int swServer_start(swServer *serv)函数, 该函数负责启动server
在函数swServer_start中会调用swReactorProcess_start, 这个函数会fork出多个worker进程
主进程和worker进程各自进入自己的事件循环, 处理各类事件
2.2 process模式
1. 说明
这种模式为多进程多线程, 有主进程, manager进程, worker进程, task_worker进程
主进程下有多个线程, 主线程负责接受连接, 之后交给react线程处理请求。 react线程负责接收数据包, 并将数据转发给worker进程进行处理, 之后处理worker进程返回的数据
manager进程, 该进程为单线程, 主要负责管理worker进程, 类似于nginx中的主进程, 当worker进程异常退出时, manager进程负责重新fork出一个worker进程
worker进程, 该进程为单线程, 负责具体处理请求
task_worker进程, 用于处理比较耗时的任务, 默认不开启
worker进程与主进程中的react线程使用域套接字进行通信, worker进程之间不进行通信
2. 启动过程
Swoole server启动入口: swServer_start函数
如果设置了daemon模式, 在必要的参数检查完后, 先将自己变为守护进程再fork manager进程, 进而创建reactor线程
主进程先fork出manager进程, manager进程负责fork出worker进程以及task_worker进程。worker进程之后进入int swWorker_loop
(swServer *serv, int worker_id), 也就是进入自己的事件循环, task_worker也是一样, 进入自己的事件循环
主进程pthread_create出react线程, 主线程和react线程各自进入自己的事件循环, reactor线程执行static int swRea-torThread_loop (swThreadParam *param), 等待处理事件
3. 结构图
Swoole process模式结构如下图所示,
上图并没有考虑task_worker进程, 在默认情况下, task_worker进程数为0
三. 请求处理流程(process模式)
3.1 reactor线程与worker进程之间的通信
1. Swoole master进程与worker进程之间的通信如下图所示
Swoole使用SOCK_DGRAM, 而不是SOCK_STREAM, 这里是因为每个reactor线程负责处理多个请求, reactor接收到请求后会将信息转发给worker进程, 由worker进程负责处理,如果使用SOCK_STREAM, worker进程无法对tcp进行分包, 进而处理请求
swFactoryProcess_start函数中会根据worker进程数创建对应个数的套接字对, 用于reactor线程与worker进程通信(详见swPipeUnsock_create函数)
2. 假设reactor线程有2个, worker进程有3个, 则reactor与worker之间的通信如下图所示
每个reactor线程负责监听几个worker进程, 每个worker进程只有一个reactor线程监听(reactor_num <= worker_num)。Swoole默认使用worker_process_id % reactor_num对worker进程进行分配, 交给对应的reactor线程进行监听
reactor线程收到某个worker进程的数据后会进行处理, 值得注意的是, 这个reactor线程可能并不是发送请求的那个reactor线程。
3. reactor线程与worker进程通信的数据包
3.2 请求处理
1. master进程中的主线程负责监听端口(listen), 接受连接(accept, 产生一个fd), 接受连接后将请求分配给reactor线程, 默认通过fd % reactor_number进行分配, 之后通过epoll_ctl将fd加入到对应reactor线程中, 刚加入时监听写事件, 因为新接受连接创建的套接字写缓冲区为空, 故而一定可写, 会被立刻触发, 进而reactor线程进行一些初始化操作
存在多个线程同时操作一个epollfd(通过系统调用epoll_create创建)的情况
多个线程同时调用epoll_ctl是线程安全的(对应一个epollfd), 一个线程正在执行, 其他线程会被阻塞(因为需要同时操作epoll底层的红黑树)
多个线程同时调用epoll_wait也是线程安全的, 但是一个事件可能会被多个线程同时接收到, 实际中不建议多个线程同时epoll_wait一个epollfd。Swoole中也是不存在这种情况的, Swoole中每个reactor线程都有自己的epollfd
一个线程调用epoll_wait, 一个线程调用epoll_ctl, 根据man手册, 如果epoll_ctl新加入的fd已经准备好, 会使得执行epoll_wait的线程变成非阻塞状态(可以通过manepoll_wait查看相关内容)
2. reactor线程中fd的写事件被触发, reactor线程负责处理, 发现是首次加入, 没有数据可写, 则会开启读事件监听, 准备接受客户端发送的数据
3. reactor线程读取到用户的请求数据,一个请求的数据接收完后, 将数据转发给worker进程, 默认是通过fd % worker_number进行分配
reactor发送给worker进程的数据包, 会包含一个头部, 头部中记录了reactor的信息
如果发送的数据过大, 则需要将数据进行分片, 限于篇幅, 数据分片, 后续再进行详细讲述
可能存在多个reactor线程同时向同一个worker进程发送数据的情况, 故而Swoole采用SOCK_DGRAM模式与worker进程进行通信, 通过每个数据包的包头, worker进程可以区分出是由哪个reactor线程发送的数据, 也可以知道是哪个请求
4. worker进程收到reactor发送的数据包后, 进行处理, 处理完成后, 将请求结果发送给主进程
worker进程发送给主进程的数据包, 也会包含一个头部, 当reactor线程收到数据包后, 能够知道对应的reactor线程, 请求的fd等信息
5. 主进程收到worker进程发送的数据包, 这个会触发某个reactor线程进行处理
这个reactor线程并不一定是之前发送请求给worker进程的那个reactor线程
主进程的每个reactor线程都负责监听worker进程发送的数据包, 每个worker发送的数据包只会由一个reactor线程进行监听, 故而只会触发一个reactor线程
6. reactor线程处理worker进程发送的请求处理结果, 如果是直接发送数据给客户端, 则可以直接发送, 如果需要改变这个这个连接的监听状态(例如close), 则需要先找到监听这个连接的reactor线程, 进而改变这个连接的监听状态(通过调用epoll_ctl)
reactor处理线程与reactor监听线程可能并不是同一个线程
reactor监听线程负责监听客户端发送的数据, 进而转发给worker进程
reactor处理线程负责监听worker进程发送给主进程的数据, 进而将数据发送给客户端
四. gdb调试
4.1 process模式启动
4.2 base模式启动
五. 总结及思考
1. 本文主要介绍了Swoole server的两种模式: base模式、process模式, 详细讲解了两种模式的网络编程模型, 并重点介绍了process模式下, 进程间通信的方式、请求的处理流程等
2. process模式下, 为什么不直接在主进程中创建多个线程, 由线程直接进行处理请求(可以避免进程间通信的开销), 而是创建出manager进程, 再由manager进程创建出worker进程, 由worker进程处理请求?
个人觉得可能是php对多线程的支持不是很友好, phper大都也只是进行单线程编程
ZendVM 提供的 TSRM 虽然也是支持多线程环境，但实际上这是一个 按线程隔离内存的方案, 多线程并没有意义
3. process模式下, 主进程中的每个reactor线程都可以同时处理多个请求, 多个请求是并发处理的, 我们从2个维度看
从主进程的角度看, 主进程同时处理多个请求, 当一个请求包全部接收完后, 转发给worker进程进行处理
从某个worker进程的角度看, 这个worker进程收到的请求是串行的, 默认情况下, worker进程也是串行处理请求, 如果单个请求阻塞(Swoole的worker进程会回调phper写的事件处理函数, 该函数可能阻塞), 后续的请求也无法处理, 这个就是排头阻塞问题, 这种情况下可以使用Swoole的协程, 通过协程的调度, 单个请求阻塞时, worker进程可以继续处理其他请求
4. 使用Swoole创建tcp server时, 由于tcp是字节流的协议, 需要分包, 而Swoole在不清楚客户端与服务端通信协议的情况下, 无法进行分包, process模式下, reactor交给worker进程的数据也只能是字节流的, 需要用户自行处理。当然, 一般情况也不需要自行构建协议, 使用tcp server, Swoole已经支持Http, Https等协议
关于“Swoole server的案例分析”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
