mirror of
https://github.com/zhamao-robot/zhamao-framework.git
synced 2026-03-18 21:24:52 +08:00
71 lines
6.7 KiB
Markdown
71 lines
6.7 KiB
Markdown
# 框架多进程
|
||
|
||
首先对于多进程概念，对于传统 PHP 程序员可能比较陌生，唯一接触到的地方可能就是 php-fpm 等一些方式处理时间长的请求时开进程去执行。关于多进程，我觉得廖雪峰的 Python 多进程这段讲的不错：
|
||
|
||
> Unix/Linux 操作系统提供了一个`fork()`系统调用，它非常特殊。普通的函数调用，调用一次，返回一次，但是`fork()`调用一次，返回两次，因为操作系统自动把当前进程（称为父进程）复制了一份（称为子进程），然后，分别在父进程和子进程内返回。
|
||
|
||
这里面的重点在于，多进程的创建，是父进程的复制，然后两个进程接下来运行的代码和存的内容就分道扬镳了。
|
||
|
||
PHP 也是如此，框架的多进程又是怎么一回事呢？为什么要采用多进程呢？
|
||
|
||
## 作用
|
||
|
||
使用过框架的你一定知道，框架是以命令行方式运行 PHP 的，而命令行方式运行 PHP，就代表要常驻内存，就像 Python、Node.js 一样。而默认情况下，比如 Python 的 Flask 为单线程单进程模式，也就是说同时只能处理一个 Web 请求。但大部分情况下，比如 Node.js，提供的都是异步 I/O，这也就是说明它在 Web 处理请求上，可同时承接的 I/O 密集型请求会更多一些，这样在对一般的 Web 应用中 I/O 密集型场景非常有用，而且往往只需要单进程也可以承载上万的并发请求。
|
||
|
||
在炸毛框架中，因为框架基于 Swoole 构建，所以天然支持协程，而协程就是针对 I/O 操作进行一个调度，类似异步的 Node.js，所以针对项目中存在太多的 SQL 语句执行、文件读写的话，炸毛框架直接上手，无需做任何修改，也可以达到很好的性能。
|
||
|
||
**但是**，CPU 密集型的应用怎么办呢？假设我的 Web 应用有大量的排序、md5 运算怎么办呢？这样的阻塞，假设是一个超级大的 for 循环或者是要执行很长时间的 while 循环，CPU 一直在被占用。多进程就是针对 CPU 密集型的应用说 yes 的一个方案。
|
||
|
||
|
||
|
||
我们假设现在有 3 个请求同时访问，也就是说上面的流程需要执行 3 遍。而如果我们只有一个进程的话，最后一个请求需要等待的时间为 `2*3+5*3=21` 秒，非常耗时。
|
||
|
||
而如果有两个进程处理 3 个请求，则最后一个完成的请求就缩短了，`2+5+2+5=14` 秒。
|
||
|
||
|
||
|
||
所以如果要充分利用你的服务器或者个人电脑的多核 CPU 资源，就要设置多个进程来处理。一个进程只能在一个 CPU 上运行，而设置了多进程后，就可以让多核 CPU 充分运行多个进程，所以我们给框架设置多进程的推荐数值为等同于 CPU 的核心数。
|
||
|
||
## 为什么不是多线程
|
||
|
||
因为众所周知，PHP 对线程的支持比较不好，而 ZTS 版本的 PHP 又会影响传统的 Web 端 PHP 的性能，再加上 Linux 对线程的切换效率和多进程切换的效率差不多，多线程容易造成数据读写不安全等问题，故 Swoole 使用的是多进程模型。
|
||
|
||
## 框架进程模型
|
||
|
||
|
||
|
||
上图中，横向的时间片可以理解为并行执行，这些操作在多个 CPU 内可能同时在执行。
|
||
|
||
## 进程间隔离
|
||
|
||
众所周知，进程是程序在操作系统中的一个边界，和自己有关的一切变量、内容和代码都在自己的进程内，不同进程之间如果不使用管道等方式，是不可以互相访问的。而加上开始描述的，创建子进程是一个复制自身的过程，所以也就会有如下图的情况：
|
||
|
||
|
||
|
||
我们以静态类为例，设置一个进程中的全局变量。这里就会出现，同一个静态变量在多个进程中完全不同的值的结果。此后，我们将会在 Worker 进程中执行用户的代码，如果设置 Worker 数量仅为 1 的话，那么就简单许多了，你还是可以使用全局变量或静态类来存储你想要的内容而不用担心这种多个进程变量隔离的情况（因为用户的 Web 请求处理的代码只会在一个 Worker 进程中执行）。如果像上图一样设置了多个 Worker，则用户过来的比如 HTTP 请求就有可能出现在不同的 Worker 进程中，给全局变量设值就一定会造成不同步的问题。这时我们就不可以使用全局变量做数据同步（注意，我说的是数据同步）。
|
||
|
||
## 跨进程同步
|
||
|
||
跨进程同步方案中，框架给出了很多种解决方案。
|
||
|
||
- MySQL 数据库
|
||
- Redis
|
||
- LightCache 轻量缓存（共享内存）
|
||
- WorkerCache 大缓存
|
||
- ZMAtomic 跨进程原子计数器
|
||
|
||
下面的表格我将列出下方的特点和各自的优缺点：
|
||
|
||
| 类型 | 用途 | 优点 | 缺点 |
|
||
| ----------- | --------------------------------------------------- | ------------------------------------------------- | ------------------------------------------------------------ |
|
||
| MySQL | 大型的传统的关系式数据都可以用数据库，你懂的 | 就是数据库的优点 | 和数据库不在同一台服务器的话网络延迟会较大，数据获取效率不高 |
|
||
| Redis | 传统的 key-value 数据库 | 数据无同步等问题，性能高 | 有网络通信延迟 |
|
||
| LightCache | 框架封装的跨进程的 key-value 存储模型 | 性能强悍，无 I/O 和网络通信 | 需要提前分配最大内存大小，最大单个值长度大小，不灵活 |
|
||
| WorkerCache | 框架封装的基于进程的 key-value 存储模型，类似 Redis | 无需提前分配最大内存大小，受限于 PHP memory_limit | 见 WorkerCache 的说明 |
|
||
|
||
!!! note "WorkerCache 的说明"
|
||
对于 WorkerCache 来说，其实是比较特殊的进程间通信。具体来说就是，WorkerCache 的原理就是将变量指定的存到一个进程中，如果是本进程读写的话直接相当于改一下全局变量，如果是其他进程读写的话，则依靠进程间通信。
|
||
|
||
所以缺点也显而易见，如果使用过程中不是命中了 WorkerCache 存储所在的进程的话，则一直会使用进程间通信，影响一定的效率。
|
||
|