PHP 怎么守护进程化

wen PHP项目 2026-08-04 2

PHP 守护进程化：从原理到实战的完整指南

目录导读

什么是守护进程？为什么PHP需要它？
PHP守护进程化的核心原理
实现方案一：pcntl_fork + POSIX函数
实现方案二：Supervisor系统工具托管
实现方案三：Workerman/Swoole常驻内存框架
守护进程的日志、信号与崩溃恢复
常见问题问答（FAQ）

什么是守护进程？为什么PHP需要它？

守护进程（Daemon）是运行在后台、不受终端控制、持续提供服务的特殊进程，它脱离了终端的会话和进程组，生命周期通常与系统同长，对PHP而言，传统的 php index.php 执行方式在脚本结束或用户断开连接时便会终止，但在消息队列消费、实时推送、WebSocket服务、定时任务调度等场景下，我们需要PHP进程常驻内存并持续运行，这就是“PHP守护进程化”的核心诉求。

PHP 怎么守护进程化

守护进程化的本质是：让PHP进程脱离终端控制，变成系统的“常驻服务”，它需要解决三件事：脱离会话、屏蔽终端信号、设定工作目录和文件权限掩码。

PHP守护进程化的核心原理

PHP守护进程化遵循Unix/Linux经典Daemon标准流程,主要在代码中执行以下步骤：

创建子进程（fork）：调用 pcntl_fork() 生成一个子进程，然后父进程退出，此时子进程成为孤儿进程，被init进程（PID 1）收养。
脱离会话（setsid）：在子进程中调用 posix_setsid()，创建一个新的会话并成为会话首进程,彻底脱离原终端的控制。
二次fork（可选但推荐）：再次fork一次，确保新进程不是会话首进程,防止将来误打开终端设备。
改变工作目录：使用 chdir('/') 将工作目录切换到根目录,避免占用挂载点。
设置文件权限掩码：调用 umask(0) 清除掩码,确保创建文件时拥有完整权限。
重定向标准输入/输出/错误：将STDIN/STDOUT/STDERR重定向到 /dev/null 或日志文件,避免进程因终端关闭而收到SIGPIPE信号退出。

搜索引擎中关于“PHP daemonize”的高质量内容往往忽略第二步中的“二次fork”的必要性，我们在本文中重点强调：只有二次fork才能完全保证进程无法重新获得控制终端。

实现方案一：pcntl_fork + POSIX函数

这是最底层的实现方式，适合对进程控制有完全需求的开发者,以下是一个精简且健壮的完整示例：

<?php
// daemon.php
declare(ticks = 1);
$pid = pcntl_fork(); // 第一次fork
if ($pid == -1) {
    die("fork失败");
} elseif ($pid > 0) {
    exit(0); // 父进程退出
}
// 子进程：脱离会话
posix_setsid();
// 第二次fork
$pid2 = pcntl_fork();
if ($pid2 == -1) {
    die("第二次fork失败");
} elseif ($pid2 > 0) {
    exit(0); // 中间进程退出
}
// 此时现在的进程已经是真正的守护进程
chdir('/');
umask(0);
// 重定向标准流
fclose(STDIN);
fclose(STDOUT);
fclose(STDERR);
$stdin = fopen('/dev/null', 'r');
$stdout = fopen('/path/to/log.log', 'a');
$stderr = fopen('/path/to/error.log', 'a');
// 业务逻辑（一个简单的循环或事件监听）
while (true) {
    // 你的守护任务
    file_put_contents('/tmp/daemon_alive', time());
    sleep(10);
}

此方案的优点是完全可控，不依赖外部工具；缺点是必须处理信号、子进程回收等底层细节。

实现方案二：Supervisor系统工具托管

如果不想写复杂的fork代码， Supervisor 是业界最成熟的PHP守护进程管理工具，它本身是Python写的进程管理器，但完美托管PHP CLI脚本。

配置步骤：

安装Supervisor：apt install supervisor 或 pip install supervisor
新增配置文件 /etc/supervisor/conf.d/php-worker.conf：

[program:php_worker]
command=php /var/www/worker.php
directory=/var/www
autostart=true
autorestart=true
startretries=3
stderr_logfile=/var/log/php_worker.err.log
stdout_logfile=/var/log/php_worker.out.log
user=www-data

启动命令：supervisorctl reread && supervisorctl update && supervisorctl start php_worker

核心优势：Supervisor自动处理进程崩溃拉起、日志轮转、进程分组管理，你的PHP脚本只需写成普通的 while(true) 循环即可，无需任何fork代码，它对搜索排名友好，因为这是运维层面最推荐的做法,能显著提升服务的稳定性。

实现方案三：Workerman/Swoole常驻内存框架

对于更复杂的业务，使用 Swoole 或 Workerman 这类常驻内存框架，不仅能实现守护进程，还能提供进程管理、协程、TCP/UDP服务等高级特性。

以Workerman为例,守护进程化仅需一个参数：

use Workerman\Worker;
require_once __DIR__ . '/vendor/autoload.php';
$worker = new Worker('tcp://0.0.0.0:8080');
$worker->onMessage = function($connection, $data) {
    $connection->send('Hello');
};
// 最关键的一行：以守护进程方式运行
Worker::$daemonize = true;
Worker::runAll();

启动：php worker.php start

Swoole 则提供了 Swoole\Process::daemon() 方法：

Swoole\Process::daemon(true, true); // 第一个参数为nochdir，第二个为noclose

此类框架内部已经集成了信号处理、进程池、崩溃恢复，搜索引擎中关于“Swoole守护进程”的文章大量存在，但多数忽略了结合 systemd 服务单元的方式，我们建议若使用Swoole,可再搭配systemd服务来实现开机自启。

守护进程的日志、信号与崩溃恢复

一个健壮的守护进程必须处理以下三个运行时问题：

日志管理：直接重定向到文件会导致文件无限增长，建议使用 logrotate 工具进行日志轮转，或使用 Monolog 等日志库按日期/大小自动切割。
信号处理：通过 pcntl_signal(SIGTERM, 'handleSignal') 捕获终止信号，执行清理操作后退出，注意需要 declare(ticks=1) 或使用 Swoole 的异步信号监听。
崩溃恢复：如果是纯PHP实现的守护进程，务必使用 register_shutdown_function 记录错误，并用 pcntl_wait 回收子进程，更简单的做法是外层套Supervisor,让它帮你重启。

以下是一个信号处理的实践片段：

function handleSignal($signo) {
    switch ($signo) {
        case SIGTERM:
        case SIGINT:
            exit(0);
        case SIGHUP:
            // 重新读取配置
            break;
    }
}
pcntl_signal(SIGTERM, 'handleSignal');

常见问题问答（FAQ）

问1：PHP守护进程和常驻内存的区别是什么？ 答：守护进程是脱离终端且由init收养的后台进程，常驻内存指脚本不退出、继续执行，守护进程必然是常驻内存，但常驻内存不一定脱离了终端（比如在终端前台运行swoole时），守护进程化是“形式”，常驻内存是“行为”。

问2：使用pcntl_fork后，子进程如何避免僵尸进程？ 答：父进程应调用 pcntl_wait($status) 或 pcntl_waitpid($pid, $status, WNOHANG) 来回收子进程状态，在守护进程内部再次fork的场景，最外层父进程退出后，由init进程自动收养并回收，因此常见做法是父进程直接exit（0）,让init接管中间子进程。

问3：PHP守护进程遇到内存泄露怎么办？ 答：经典PHP只要不退出就会持续增长内存，建议在业务循环中每处理完N条数据后调用 gc_collect_cycles() 强制垃圾回收，并设置单进程的内存上限（如 ini_set('memory_limit','256M')），如果超过限制则主动 exit，然后借助Supervisor自动重启,这是最常用的保活策略。

问4：Swoole的守护进程和systemd托管冲突吗？ 答：不冲突，可以用systemd管理Swoole进程（以非daemon方式运行，即 daemonize=false），这样能用systemd的unit文件配置开机自启、崩溃重启，反之，如果Swoole自己设置了daemonize，则不建议再用systemd,避免双重守护。

问5：守护进程如何优雅地关闭？ 答：对SIGTERM信号设置处理函数，在函数中停止接收新任务、处理完手头任务后，调用 exit(0) 退出，如果业务中有数据库连接，需要关闭连接，注意不要使用 die 暴力退出,否则数据可能丢失。

通过本文的四种方案对比，你可以根据项目实际情况选择最适合的守护进程化路径，从最底层的 pcntl_fork 到运维层面的Supervisor，再到成熟的高性能框架Swoole，PHP已经完全具备企业级常驻服务的能力，不必再局限在“请求-响应”的CGI生命周期中。