我应该为此使用消息队列吗？答案

【问题标题】：Should I be using message queuing for this?我应该为此使用消息队列吗？
【发布时间】：2011-06-30 02:22:03
【问题描述】：

我有一个 PHP 应用程序，目前有 5k 用户，并且在可预见的未来会不断增加。我每周运行一次脚本：

此脚本上次运行时，由于 30 秒的最大执行时间错误，它只处理了 1400 个用户，然后死掉了。我想到的一个解决方案是让主脚本仍然获取所有用户，但不是自己执行维护过程，而是对一个执行维护的新脚本进行异步 cURL 调用（每个用户 1 个）特定用户。

我担心的是 5k+ cURL 调用可能会导致服务器宕机。这是否可以通过使用消息队列而不是 cURL 调用来解决？我没有使用过的经验，但从我所读到的内容看来，这可能会有所帮助。如果是这样，您会推荐哪种消息队列系统？

一些背景信息：

非常感谢任何建议和帮助。

【问题讨论】：

【解决方案1】：

如果可能的话，我会创建一个运行频率更高的计划任务（cron 作业），并使用LIMIT 100（或其他数字）一次处理有限数量的用户。

【讨论】：

【解决方案2】：

一些想法：

增加脚本执行时间限制 - set_time_limit()
不要过火，但 30 秒以上是一个开始。
跟踪用户维护
也许为每个用户添加一个字段 last_check 并将该字段设置为对该用户执行的最后一次成功的“维护”操作的日期/时间。
处理较小的批次
最好更频繁地运行小批量。把它想象成 PHP 相当于“你所有的鸡蛋都放在一个以上的篮子里”。使用上面的 last_check 字段，可以轻松识别自上次更新以来周期最长的那些，并设置处理频率的阈值。
经常跑步
设置一个 cronjob 和进程，比如每 2 分钟 100 条记录或类似的东西。
记录并查看您的表现
拥有日志文件并记录统计信息。处理了多少条记录，距离上次处理多长时间，脚本用了多长时间。这些指标将允许您调整批处理大小、cronjob 设置、时间限制等，以确保以稳定的方式执行最大检查。

与单个进程相比，设置所有这些可能听起来像是很多工作，但它可以让您处理增加的用户量，并为您可能正在关注的任何进一步维护任务奠定坚实的基础。

【讨论】：

【解决方案3】：

你为什么不仍然使用 cURL 的想法，而不是只为每个用户处理一个用户，而是通过将一组用户分成 1000 个或其他的组来发送一组用户。

【讨论】：

【解决方案4】：

您是否考虑过在处理每个用户时更改逻辑以提交更改？听起来您可能正在运行单个事务来处理所有用户，这可能不是必需的。

【讨论】：

【解决方案5】：

只增加PHP的执行时间限制怎么样？

此外，研究是否可以改进维护程序以使其更快也可以提供帮助。根据您的具体操作，您还可以考虑将其分散一点。偶尔做几次，而不是一次做一次。但当然取决于你到底在做什么。

【讨论】：