Workerman通过PHP-CLI独立运行，常驻内存、多进程监听端口，支持长连接与高并发，适用于实时通信等场景；而传统PHP-FPM依赖Web服务器，每次请求重建环境，适合短连接Web应用。
Workerman的运行，从根本上讲，就是让你的PHP脚本不再仅仅是Web服务器的一个“打工仔”，而是自己摇身一变，成为一个独立的、常驻内存的服务器进程。它不再依赖Nginx或Apache来启动和管理，而是直接在命令行下通过PHP-CLI环境被执行，然后持续监听特定的网络端口，处理客户端的连接和数据。启动方式主要就是两种：一种是前台调试模式，方便开发时查看输出；另一种是后台守护进程模式，用于生产环境的稳定运行。
Workerman的运行，其实并不复杂，但它改变了我们对PHP应用运行方式的固有认知。当你执行一个Workerman的启动脚本时，你不是在通过HTTP请求触发一个PHP文件，而是在直接启动一个服务。
解决方案
要让Workerman跑起来，核心就是通过PHP命令行工具（php-cli）去执行你的启动脚本。
最基本的启动命令是：
php your_start_script.php start
这里的
your_start_script.php
是你自己编写的Workerman应用入口文件，它会定义Workerman监听的端口、协议以及处理逻辑。
在开发和调试阶段，我们通常会使用前台模式启动，这样所有的输出（比如
echo
、
var_dump
）都会直接显示在终端，方便我们观察和排查问题：
php your_start_script.php start
这时，只要终端窗口不关闭，Workerman就会一直运行。如果你想停止它，直接按
Ctrl+C
即可。
而到了生产环境，我们当然不希望Workerman的运行依赖于一个打开的终端。这时候就需要以守护进程（daemon）模式启动，让它在后台默默运行，即使你关闭了终端，它也不会停止：
php your_start_script.php start -d
这个
-d
参数至关重要，它告诉Workerman在后台以守护进程的方式运行。一旦启动成功，你就可以关闭终端了。
除了启动，Workerman还提供了一些常用的管理命令：
停止 (stop): 优雅地停止所有Workerman进程。
php your_start_script.php stop
如果遇到无法停止的情况，可以尝试强制停止：
php your_start_script.php stop -g
重启 (restart): 停止后重新启动，常用于更新代码后让新代码生效。
php your_start_script.php restart
平滑重启 (reload): 在不中断服务的情况下，平滑地重新加载业务代码。这个功能在生产环境非常有用，可以做到无感更新。
php your_start_script.php reload
需要注意的是，
reload
只会重新加载业务代码，Worker进程本身不会重启。如果你修改了Workerman的配置（例如监听端口），则需要
restart
。
查看状态 (status): 查看Workerman当前运行状态，包括进程ID、内存占用、连接数等信息。
php your_start_script.php status
这些命令，构成了Workerman日常运维的基础。理解它们，基本上就能驾驭Workerman的生命周期了。
Workerman运行环境有哪些核心要求？
要让Workerman顺利地跑起来，并发挥其应有的性能，对运行环境还是有一些基本要求的，这些要求往往被新手忽略，导致一些莫名其妙的问题。
首先，也是最核心的，你需要一个PHP-CLI环境。Workerman是基于命令行运行的，而不是通过Web服务器（如Apache或Nginx）的PHP-FPM模块来执行。所以，确保你的服务器上安装了
php-cli
，并且版本符合你的Workerman项目要求（通常PHP 7.0+ 是推荐的）。你可以在终端输入
php -v
来检查。
其次，PHP的扩展支持非常关键。Workerman在Linux系统下，强烈依赖
pcntl
和
posix
这两个PHP扩展。
pcntl
（Process Control）用于进程管理，比如创建子进程（fork）、信号处理等；
posix
则提供了访问POSIX系统接口的功能，比如获取进程ID、设置用户组等。这两个扩展是Workerman实现多进程模型和守护进程模式的基石。如果缺少它们，Workerman可能无法正常启动或运行不稳定。你可以在
php.ini
中检查是否开启，或者通过
php -m
查看已加载的扩展列表。Windows环境下，Workerman通常运行在单进程模式，对这两个扩展的需求没那么严格，但其性能和稳定性会大打折扣，所以生产环境强烈建议在Linux系统下部署。
再者，系统资源。虽然Workerman本身很轻量，但作为服务器，它会占用端口、内存和CPU。你需要确保服务器有足够的内存来支撑你的Worker进程数量以及每个进程处理的连接数。同时，操作系统的文件描述符限制（ulimit -n）也需要注意。每个客户端连接都会占用一个文件描述符，如果你的应用需要支持大量并发连接，就需要调高这个限制，否则Workerman可能会报告“Too many open files”错误。默认的1024通常是不够的。
一览运营宝
一览“运营宝”是一款搭载AIGC的视频创作赋能及变现工具，由深耕视频行业18年的一览科技研发推出。
41 查看详情 
最后，网络环境。Workerman需要监听端口来接收客户端连接。确保你选择的端口没有被其他程序占用，并且服务器的防火墙（如
firewalld
或
iptables
）允许外部访问这些端口。这是一个很常见的部署初期问题。
Workerman在实际部署中，如何保障其稳定性和高可用性？
在生产环境中部署Workerman，仅仅能跑起来是远远不够的，我们更关心的是它的稳定性和高可用性。毕竟，一个服务如果动不动就挂掉，那用户的体验和业务的连续性都会受到严重影响。
我的经验告诉我，保障Workerman的稳定性和高可用性，主要从以下几个方面入手：
1. 进程守护与管理： Workerman虽然有自己的守护进程模式，但为了应对极端情况（比如服务器重启、Workerman自身因未知错误崩溃），我们通常会引入更专业的进程管理工具。
Systemd: 在现代Linux发行版中，
systemd
是主流的服务管理工具。你可以为Workerman编写一个
systemd
服务单元文件（
.service
文件），定义Workerman的启动、停止、重启命令，以及在崩溃时自动重启的策略。这样，即使Workerman进程意外退出，
systemd
也能及时把它拉起来。Supervisor:
Supervisor
是另一个非常流行的进程管理工具，它用Python编写，配置简单，功能强大。它能够监控Workerman进程，在进程退出时自动重启，并且可以很方便地管理多个Workerman应用。对于一些老旧系统或者不方便使用
systemd
的场景，
Supervisor
是个不错的选择。
2. 完善的日志系统： 任何服务在运行中都可能出现问题，日志是排查问题的唯一线索。Workerman本身会输出一些运行日志，但更重要的是你的业务逻辑日志。
分级日志： 区分
DEBUG
、
INFO
、
WARNING
、
ERROR
等不同级别的日志，在生产环境只记录
INFO
及以上级别，必要时再开启
DEBUG
。日志轮转： 配合
logrotate
工具，定期对日志文件进行切割、压缩和删除，防止日志文件无限增长占满磁盘。集中式日志系统： 如果你的服务规模较大，可以考虑使用ELK Stack（Elasticsearch, Logstash, Kibana）或Grafana Loki等集中式日志系统，方便统一收集、检索和分析日志。
3. 资源监控与告警： 实时监控Workerman进程的CPU、内存、连接数等关键指标，一旦超出预设阈值，立即触发告警。
Prometheus + Grafana: 这是一个非常强大的组合，可以收集Workerman的各种运行时指标，并通过Grafana进行可视化展示，方便你实时掌握服务状态。Zabbix/Nagios: 传统的监控工具也能派上用场，用于监控服务器整体资源和Workerman进程的存活状态。自定义告警： 结合监控数据，设置邮件、短信、微信或钉钉等告警通知，确保问题发生时能第一时间被发现并处理。
4. 平滑重启与无感更新： Workerman的
reload
命令是实现业务代码无感更新的关键。当你的业务逻辑代码有更新时，执行
php your_start_script.php reload
，Workerman会向所有Worker进程发送一个信号，让它们处理完当前请求后退出，并启动新的Worker进程加载新代码。这样，用户几乎感受不到服务中断。但要注意，
reload
不能用于更新Workerman的配置或底层依赖，那种情况必须
restart
。
5. 异常处理与容错： 在你的业务代码中，要充分考虑各种异常情况，并做好相应的捕获和处理，避免因为一个小的逻辑错误导致整个Worker进程崩溃。例如，数据库连接失败、外部API调用超时、数据格式错误等，都应该有健壮的
try-catch
块。
通过这些措施的综合运用，Workerman服务在生产环境下的稳定性和高可用性才能得到有效保障，从而支撑起你的业务需求。
Workerman与传统Web服务器（如Nginx+PHP-FPM）的运行机制有何本质区别？
Workerman和Nginx+PHP-FPM，虽然都能用来处理PHP应用，但它们在运行机制上存在着根本性的差异，理解这些差异，对于选择合适的架构和优化应用性能至关重要。我个人觉得，这就像是两种完全不同的“生活方式”。
1. 生命周期与进程模型：
Nginx+PHP-FPM： 这是一个典型的“短连接”模型。当一个HTTP请求到达Nginx时，Nginx会将请求转发给PHP-FPM。PHP-FPM会创建一个新的PHP进程（或者从进程池中取出一个空闲进程），执行你的PHP脚本，生成响应，然后将响应返回给Nginx，Nginx再返回给客户端。这个PHP进程在处理完一次请求后，就会被销毁或回到进程池等待下一个请求。 每次请求，PHP应用环境都会被重新初始化一遍。Workerman： 这是一个“长连接”模型。当你启动Workerman时，它会fork出多个子进程（Worker进程），这些进程会常驻内存，持续监听端口。每个Worker进程在启动后，会一直运行，不会因为一个请求处理完毕就退出。 这意味着，你的PHP应用环境（包括数据库连接、缓存连接、全局变量等）在Worker进程的生命周期内都是持续存在的，只会被初始化一次。
2. 协议支持与应用场景：
Nginx+PHP-FPM： 主要专注于处理HTTP/HTTPS协议。它非常适合传统的Web网站、RESTful API等短连接、无状态的应用。Workerman： 它是一个通用的Socket服务器框架，可以支持TCP、UDP、WebSocket、HTTP等多种协议。这使得它非常适合开发实时应用，如聊天室、消息推送、物联网（IoT）设备通信、游戏服务器，以及需要长时间保持连接或处理非HTTP协议的场景。它也可以处理HTTP请求，但其优势在于长连接和自定义协议。
3. 资源消耗与性能：
Nginx+PHP-FPM： 每次请求都需要初始化PHP环境，包括加载框架、连接数据库等，这会带来一定的启动开销。在高并发下，频繁的进程创建/销毁和上下文切换也会消耗资源。Workerman： 由于Worker进程常驻内存，PHP环境只初始化一次，后续请求可以直接使用已有的资源（如数据库连接池）。这大大减少了重复初始化开销，使得它在处理长连接和高并发时，通常能表现出更高的性能和更低的资源占用。对于需要大量I/O操作（如文件读写、网络请求）的场景，Workerman的事件驱动、非阻塞I/O模型也能发挥优势。
4. 编程模型与架构：
Nginx+PHP-FPM： 典型的“请求-响应”模式，PHP脚本的执行是线性的，一个请求一个进程。Workerman： 采用事件驱动、非阻塞I/O的编程模型。你的代码逻辑是基于事件回调来组织的，当有数据到达、连接关闭等事件发生时，对应的回调函数才会被触发执行。这种模型使得一个Worker进程可以同时处理多个连接，提高了并发处理能力。
简单来说，如果你只是想搭建一个传统的Web网站或API服务，Nginx+PHP-FPM是成熟、稳定的选择。但如果你需要构建实时通信、长连接服务，或者对性能和资源利用率有更高要求，Workerman则能提供更强大的能力和更灵活的架构。我个人觉得，Workerman的出现，真正拓宽了PHP在服务器端应用的边界，让PHP不再只是一个“Web语言”，而是一个可以构建任何网络服务的强大工具。
以上就是Workerman怎么运行？Workerman启动方式有哪些？的详细内容，更多请关注php中文网其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/422802.html
微信扫一扫 
支付宝扫一扫 
