启动&从后端管理网页停止 PHP 脚本
我正在尝试创建一个允许我启动和停止 PHP 脚本的网页。该脚本是站点后端的一部分，需要访问、读取数据、处理该数据以及更新脚本所在的同一服务器上的数据库。此外，我希望该网页允许管理员查看当前状态（正在运行或已停止），甚至链接到脚本创建的日志。 我开始走上学习 PHP 的 exec、passthru 和相关函数的道路。这是正确的道路吗？还有其他更合适的方法吗？是否可以以与平台无关的方式做到这一点？我正在 Windows 中的 LAMPP+CakePHP 堆栈上进行开发，并且希望该功能存在于我选择的任何网络主机上。
I'm trying to create a webpage that will allow me to start and stop of a PHP script. The script is part of the backend of a site, and will need to access, read data from, process that data, and update a database on the same server the script exists on. Additionally, I'd like the webpage to allow an administrator to view the current status (running or stopped), and even link to logs created by the script.
I'm starting to go down the path of learning about PHP's exec, passthru, and related functions. Is this the correct path to take? Are there other ways to do this that would be more suitable? Is it possible to do this in a platform agnostic way? I'm developing on a LAMPP+CakePHP stack in Windows, and would like the functionality to exist on any webhost I choose.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我在最近的一份工作中做到了这一点，但这对你来说可能有点过分了。我做了一个作业处理器，它基本上在数据库中设置了 2 个表，至少 2 个对象，至少 2 个控制器。
第一部分是作业处理单元，它由一个作业处理器控制器组成，用于管理启动或继续作业的请求，它带有两个 ActiveRow 模型 JobQueue 和 Job。您可以删除队列，但在此类系统中进行排队总是很实用的，因此您可以说可以同时执行 2、3、4 个作业。
队列只是一个槽，它附加了多个作业，并且有一个队列状态来确定它现在是否正在运行。
作业是一个虚拟对象，映射到描述必须完成的操作的作业表。在我的实现中，我创建了一个必须实现到被调用的控制器中的接口以及数据库中的字段+类型。作业实例化要调用的控制器类（不是作业处理器控制器，而是管理要执行的操作的另一个控制器）并调用其中的方法来启动任务处理。
现在，为了变得棘手，我强迫我的系统在专用服务器上运行，只用于该部分，因为我不希望该任务加载主服务器或堵塞 Apache 的处理队列。所以我有两台服务器，我的 Queue 类负责通过 IP 地址调用另一台服务器上的页面来专门在该服务器上运行作业。当作业完成后，它使用 HTTP 请求回调自身以重新开始处理并执行下一个任务。如果没有留下任何任务，那么它就会正常死亡。
这样做的好处是它不需要 cronjob（只要你的脚本超级稳定并且不会崩溃），因为它会在你想要的时候被你触发，然后你可以放开它，它会调用自己返回 fsockopen 以触发另一个页面视图，从而触发下一个作业。
工作单位
重要的是要了解，如果您的工作非常大，则应该对其进行细分。我使用“工作单元”的原则来描述工作中必须执行任意多次的部分。然后队列处理器也成为一个时间管理器，这样他就可以检测一个作业是否花费了超过 X 秒，它会简单地将其余步骤推迟到稍后，然后回调自己并继续他所在的位置。这样，您就不需要“设置时间限制”，并且在执行 30 秒的脚本时不会堵塞服务器。
我希望这有帮助！
I've done this in a recent job but it's probably overkill for you. I did a job processor and it basically sets 2 tables in the database, 2 objects at a minimum and 2 controllers at a minimum.
The first part is the job processing unit, it is composed of a job processor controller that manages the request to start or continue a job and it comes with two activerow models JobQueue and Job. You can remove the queue, but it's always practical to have queing in such systems so you can say that 2,3,4 jobs could execute at once.
The queue is only that, it's a slot that gets several jobs attached to it and it has a queue status to determine if it is running right now or not.
The job is a virtual object that maps to a job table describing what has to be done. In my implementation, i have created an interface that must be implemented into the called controller and a field + a type in the database. The Job instanciates the controller class to call (not the job processor controler, another controler that manages the operation to do) and calls a method in it to start the task processing.
Now, to get tricky, i forced my system to run on a dedicated server just for that portion because i didn't want the task to load the main server or jam the processing queue of Apache. So i had two servers and my Queue class was in charge of calling via an ip address a page on another server to run the job on that server specifically. When the job was done, it called itself back using a HTTP request to restart processing and do the next task. If no task was left, then it would simply die normally.
The advantage of doing it this way is that it doesn't require a cronjob (as long as your script is super stable and cannot crash) because it gets triggered by you when you want it and then you can let it go and it calls itself back with a fsockopen to trigger another page view that triggers the next job.
Work units
It is important to understand that if your jobs are very large, you should segment them. I used the principle of a "work unit" to describe 1 part the job has to do any number of times. Then the Queue Processor became a time manager too so that he could detect if a job took more than X seconds, it would simply defer the rest of the steps for later and call itself back and continue were he was at. That way, you don't need to "set time limit" and you don't jam your server while a 30s script gets executed.
I hope this helps!
要运行一个持续运行的脚本，您需要考虑：
您的 php 脚本应该由 cron 等作业调度程序作为 CLI（命令行） 启动。不要忘记您的 Web 服务器配置定义了执行脚本的超时。
为了一天 24 小时运行，也许你会想象实现一个无限循环。在这种情况下，您可以编写一个像 jobIsActive 这样的测试，它在每个循环中读取文件或数据库中是否应该执行作业。如果单击该按钮，只需更改作业状态（更新文件、数据库...）。您的两个按钮都可以停止治疗或激活治疗，但不能停止无限循环。
无限循环不是最优雅的解决方案，为什么不在 cron 选项卡中编写一个条目来每晚执行该作业，然后单击按钮可以手动启动它。
To run a script which run continually, you need think to that:
Your php script should be launched as CLI (command line) by a job scheduler like cron or something else. Don't forget that your web server configuration defined a timeout on executed script.
To run 24h a day, maybe you imagine to implement an infinite loop. In that case, you can write a test like jobIsActive which read in a file or in the database every loop if the job should be executed or not. If you click on the button just change the job status (update file, db ...). Your both button can stop the treatment or activate it but doesn't stop the infinite loop.
An infinite loop isn't the most elegant solution, why don't you write an entry in the cron tab to execute the job each night and a click on a button can fired it manually.