swoole模式

SWOOLE_PROCESS

Server所有客户端的TCP连接都是和主进程建立的，内部实现比较复杂，用了大量的进程间通信、进程管理机制。适合业务逻辑非常复杂的场景，可以应对大量慢速连接和逐字节的恶意客户端

优点

1. 连接与数据请求发送是分离的，不会因为某些连接数据量大某些连接数据量小导致Worker进程不均衡
2. Worker进程发生致命错误时，连接并不会被切断
3. 可实现单连接并发，仅保持少量TCP连接，请求可以并发地在多个Worker进程中处理

缺点

1. 存在2次IPC的开销，master进程与worker进程需要使用unixSocket进行通信

SWOOLE_BASE

1. 传统的异步非阻塞Server。与Nginx和Node.js等程序是完全一致的。worker_num参数对于BASE模式仍然有效，会启动多个Worker进程
2. 当有TCP连接请求进来的时候，所有的Worker进程去争抢这一个连接，并最终会有一个worker进程成功直接和客户端建立TCP连接，之后这个连接的所有数据收发直接和这个worker通讯，不经过主进程的Reactor线程转发
3. 没有master进程，只有manager进程
4. worker进程同时承担了SWOOLE_PROCESS模式下Reactor线程和Worker进程两部分职责
5. 设置了worker_num=1，并且没有使用Task和MaxRequest特性时，底层将直接创建一个单独的Worker进程，不创建Manager进程

优点

1. 没有IPC开销，性能更好
2. 代码更简单，不容易出错

缺点

1. 某个Worker进程挂掉时，此Worker内的所有连接都将被关闭
2. 少量TCP长连接无法利用到所有Worker进程
3. TCP连接与Worker是绑定的，长连接应用中某些连接的数据量大，这些连接所在的Worker进程负载会非常高。但某些连接数据量小，所以在Worker进程的负载会非常低，不同的Worker进程无法实现均衡
4. 如果回调函数中有阻塞操作会导致Server退化为同步模式，此时容易导致TCP的backlog队列塞满问题

使用场景

1. 客户端连接之间不需要交互

限制

1. 除了send和close以外，其他的方法都不支持跨进程执行