我正在尝试构建一个服务，该服务将每隔一定时间从web收集一些数据，然后解析这些数据，最后根据解析结果执行专用过程。服务运行的典型示意图：
- 请求将项目列表更新为
- 下载所列项目的数据
- 检查尚未更新的内容
- 更新数据库
- 筛选包含更新的数据（仅获取优先级最高的更新）
- 执行一些过程来分析更新
- 筛选包含更新的数据（仅获取中等优先级的更新）
- 执行一些过程进行分析。。。。。。
如果没有那么多数据需要更新，一切都会很简单。由于需要更新的数据太多，在从1到8（可能除了1）的每一步中，由于最长执行时间为60秒的限制，脚本都会失败。即使有增加它的选项，这也不是最佳的，因为该项目的主要目标是首先提供最高优先级的数据。不幸的是，定义信息的优先级是基于获取大部分数据，并在已经存储的数据和传入（更新）数据之间进行大量比较。
我可以放弃服务速度，以获得至少高优先级的更新作为交换，并等待更长的时间等待所有其他更新。我想写一些父脚本（管理器）来控制服务的每一步（1-8），也许可以通过执行其他脚本？管理器应该能够继续未完成的步骤（脚本）以完成它。可以这样写每一步，它将完成一小部分代码，并在完成后将这一小部分工作标记为在SQL DB中完成。在管理器恢复后，步骤（脚本）将继续执行，直到它因超过maxexec而被服务器终止为止。时间
已知的平台限制：远程服务器，不可更改的最长执行时间，通常限制同时解析一个脚本，缺乏对许多apache功能的访问，以及远程服务器的所有其他典型限制
要求：某种类型的管理器是强制性的，因为除了调用特定的脚本外，这个父进程还必须写一些关于被激活的脚本的注释。
经理可以通过crul呼叫，间隔一分钟就足够了。不幸的是，为curl列出对服务的每一步的调用列表并不是一种选择。
我还考虑为服务的每一步获取新的远程主机，并由另一个远程主机控制它们，该远程主机可以调用它们并要求使用ie SOAP完成它们的工作，但这种情况在我希望的解决方案列表的末尾，因为它不能解决最长执行时间的问题，并且通过全局网络交换大量数据。witch是处理数据的最慢方式。
对如何实施解决方案有什么想法吗？
我看不出第2步和第3步本身是如何执行超过60秒的。如果在步骤2中使用curl_multi_exec，它将在几秒钟内运行。如果您在第3步中获得的脚本超过60秒，那么您会得到"超出内存限制"，而且会更早。
所有这些都让我得出了一个结论，即脚本是非常未优化的。解决方案是：
-
将任务分解为（a）更新什么并将其保存在数据库中（比如标志1表示更新什么，0表示不更新什么）；（b） 循环遍历需要更新的行并更新它们，将flag设置为0。在大约50秒时关闭（假设脚本每隔几分钟运行一次，那就可以了）。
-
获得第二个服务器，并设置一个适当的执行时间来运行脚本数小时。由于它可以访问您的第一个数据库（而不是通过http调用），因此流量不会大幅增加。