PHP 中消息队列和工作系统的有效架构？
Valid Architecture for a Message Queue & Worker System in PHP?
我正在努力思考要在 PHP 应用程序中实现的消息队列模型和作业：
我的目标是卸载需要发送到多个第三方 API 的消息/数据，因此访问它们不会降低客户端的速度。所以将数据发送到消息队列是最理想的。
我考虑过只使用 Gearman 来保存 MQ/Jobs，但我想使用像 SQS 或 Rackspace 云队列这样的云队列服务，这样我就不必管理消息了。
这是我认为我应该做的图表：
问题：
我的工人，会写成PHP他们都必须轮询云队列服务吗？这可能会变得昂贵，尤其是当你有很多工人时。
我在想也许有 1 个工作人员只是为了轮询队列，如果有消息，通知其他工作人员他们有工作，我只需要让这 1 个工作人员在线使用 supervisord 也许？这种轮询方法比使用可以通知的 MQ 更好吗？我应该如何轮询 MQ，每秒一次或尽可能快地轮询？如果我发现它变慢了，然后增加轮询工作人员？
我也在考虑为所有消息设置一个队列，然后工作人员监控根据需要处理消息的位置将消息分发到其他云 MQ，因为可能需要 1 条消息由 2 个 diff worker 处理。
我是否还需要 gearman 来管理我的工人，还是我可以只使用 supervisord 来上下调动工人？
在发送消息时也向主要工作人员发送通知与轮询 MQ 相比是否更有效、更快速？我假设我需要使用 gearman 来通知我的主要工作人员 MQ 有一条消息，以便它可以开始检查它。或者如果我每秒有 300 条消息，这将生成 300 个作业来检查 MQ？
基本上我怎样才能尽可能有效地检查 MQ？
对我的架构有建议或更正吗？
我会推荐一条不同的路线，那就是使用套接字。 ZMQ 是一个已经编写的基于套接字的库的示例。使用套接字，您可以创建 Q 并在消息传入时管理如何处理消息。机器将处于待机模式并在等待消息传入时使用最少的资源。
我的建议基本上可以归结为：保持简单！
考虑到这一点，我的第一个建议是放弃 DispatcherWorker。根据我目前的理解，worker 的唯一目的是监听 MAIN 队列并将消息转发到不同的任务队列。您的应用程序应该负责将正确的消息排入正确的队列（或主题）。
回答您的问题：
My workers, would be written in PHP they all have to be polling the cloud queue service? that could get expensive especially when you have a lot of workers.
是的，天下没有免费的午餐。当然，您可以通过 day/week 时间（如果您的用户在特定时间处于活动状态）应用程序使用情况（当更多消息到达时增加轮询率）来调整和优化您的工作人员轮询率，等等。请记住，工程成本可能很快就会高于未优化的轮询。
相反，您可以考虑 推送队列（见下文）。
I was thinking maybe have 1 worker just for polling the queue, and if there are messages, notify the other workers that they have jobs, i just have to keep this 1 worker online using supervisord perhaps? is this polling method better than using a MQ that can notify? How should I poll the MQ, once every second or as fast as it can poll? and then increase the polling workers if I see it slowing down?
这听起来太复杂了。通信是不可靠的，但是有可靠的消息队列。如果您不想丢失数据，请坚持使用消息队列并且不要发明自定义协议。
I was also thinking of having a single queue for all the messages, then the worker monitoring that distributes the messages to other cloud MQs depending on where they need to be processed, since 1 message might need to be processed by 2 diff workers.
如前所述，应用程序应根据需要将您的消息排入多个队列。这使事情变得简单和到位。
Would I still need gearman to manage my workers or can I just use supervisord to spin workers up and down?
消息队列如此之多，使用它们的方法也更多。一般来说，如果您使用 轮询队列，您需要自己让您的工作人员保持活力。但是，如果您使用 推送队列 ，队列服务将调用您指定的端点。因此，您只需要确保您的员工有空。
Basically how could I check the MQ as efficiently and as effectively as possible?
这取决于您的业务要求和您的员工所做的工作。什么时间跨度是关键的？秒、分钟、小时、天？如果您使用 worker 发送电子邮件，则不应花费数小时，最好是几秒钟。每 3 秒或每 15 秒轮询（对用户而言）有区别吗？
正在解决您的问题（使用推送队列）：
My goal is to offload messages / data that needs to be sent to multiple third party APIs, so accessing them doesnt slow down the client. So sending the data to a message queue is ideal. I considered using just Gearman to hold the MQ/Jobs, but I wanted to use a Cloud Queue service like SQS or Rackspace Cloud Queues so i wouldnt have to manage the messages.
确实，您描述的场景非常适合消息队列。
正如您提到的，您不想管理消息队列本身，也许您也不想管理工作人员？这是 推送队列 出现的地方。
推送队列基本上呼叫你的工作人员。例如，Amazon ElasticBeanstalk 工作环境在后台执行繁重的工作（轮询），并使用包含队列消息 (refer to the docs for details). I have personally used the AWS push queues and have been happy with how easy they are. Note, that there are other push queue providers like Iron.io.
的 HTTP 请求简单地调用您的应用程序
正如您提到的，您正在使用 PHP，Symfony 有 QPush Bundle，它处理传入的消息请求。您可以查看代码来推出自己的解决方案。
我正在努力思考要在 PHP 应用程序中实现的消息队列模型和作业：
我的目标是卸载需要发送到多个第三方 API 的消息/数据，因此访问它们不会降低客户端的速度。所以将数据发送到消息队列是最理想的。
我考虑过只使用 Gearman 来保存 MQ/Jobs，但我想使用像 SQS 或 Rackspace 云队列这样的云队列服务，这样我就不必管理消息了。
这是我认为我应该做的图表：
问题：
我的工人，会写成PHP他们都必须轮询云队列服务吗？这可能会变得昂贵，尤其是当你有很多工人时。
我在想也许有 1 个工作人员只是为了轮询队列，如果有消息，通知其他工作人员他们有工作，我只需要让这 1 个工作人员在线使用
supervisord也许？这种轮询方法比使用可以通知的 MQ 更好吗？我应该如何轮询 MQ，每秒一次或尽可能快地轮询？如果我发现它变慢了，然后增加轮询工作人员？我也在考虑为所有消息设置一个队列，然后工作人员监控根据需要处理消息的位置将消息分发到其他云 MQ，因为可能需要 1 条消息由 2 个 diff worker 处理。
我是否还需要
gearman来管理我的工人，还是我可以只使用supervisord来上下调动工人？在发送消息时也向主要工作人员发送通知与轮询 MQ 相比是否更有效、更快速？我假设我需要使用
gearman来通知我的主要工作人员 MQ 有一条消息，以便它可以开始检查它。或者如果我每秒有 300 条消息，这将生成 300 个作业来检查 MQ？基本上我怎样才能尽可能有效地检查 MQ？
对我的架构有建议或更正吗？
我会推荐一条不同的路线，那就是使用套接字。 ZMQ 是一个已经编写的基于套接字的库的示例。使用套接字，您可以创建 Q 并在消息传入时管理如何处理消息。机器将处于待机模式并在等待消息传入时使用最少的资源。
我的建议基本上可以归结为：保持简单！
考虑到这一点，我的第一个建议是放弃 DispatcherWorker。根据我目前的理解，worker 的唯一目的是监听 MAIN 队列并将消息转发到不同的任务队列。您的应用程序应该负责将正确的消息排入正确的队列（或主题）。
回答您的问题：
My workers, would be written in PHP they all have to be polling the cloud queue service? that could get expensive especially when you have a lot of workers.
是的，天下没有免费的午餐。当然，您可以通过 day/week 时间（如果您的用户在特定时间处于活动状态）应用程序使用情况（当更多消息到达时增加轮询率）来调整和优化您的工作人员轮询率，等等。请记住，工程成本可能很快就会高于未优化的轮询。
相反，您可以考虑 推送队列（见下文）。
I was thinking maybe have 1 worker just for polling the queue, and if there are messages, notify the other workers that they have jobs, i just have to keep this 1 worker online using supervisord perhaps? is this polling method better than using a MQ that can notify? How should I poll the MQ, once every second or as fast as it can poll? and then increase the polling workers if I see it slowing down?
这听起来太复杂了。通信是不可靠的，但是有可靠的消息队列。如果您不想丢失数据，请坚持使用消息队列并且不要发明自定义协议。
I was also thinking of having a single queue for all the messages, then the worker monitoring that distributes the messages to other cloud MQs depending on where they need to be processed, since 1 message might need to be processed by 2 diff workers.
如前所述，应用程序应根据需要将您的消息排入多个队列。这使事情变得简单和到位。
Would I still need gearman to manage my workers or can I just use supervisord to spin workers up and down?
消息队列如此之多，使用它们的方法也更多。一般来说，如果您使用 轮询队列，您需要自己让您的工作人员保持活力。但是，如果您使用 推送队列 ，队列服务将调用您指定的端点。因此，您只需要确保您的员工有空。
Basically how could I check the MQ as efficiently and as effectively as possible?
这取决于您的业务要求和您的员工所做的工作。什么时间跨度是关键的？秒、分钟、小时、天？如果您使用 worker 发送电子邮件，则不应花费数小时，最好是几秒钟。每 3 秒或每 15 秒轮询（对用户而言）有区别吗？
正在解决您的问题（使用推送队列）：
My goal is to offload messages / data that needs to be sent to multiple third party APIs, so accessing them doesnt slow down the client. So sending the data to a message queue is ideal. I considered using just Gearman to hold the MQ/Jobs, but I wanted to use a Cloud Queue service like SQS or Rackspace Cloud Queues so i wouldnt have to manage the messages.
确实，您描述的场景非常适合消息队列。 正如您提到的，您不想管理消息队列本身，也许您也不想管理工作人员？这是 推送队列 出现的地方。
推送队列基本上呼叫你的工作人员。例如，Amazon ElasticBeanstalk 工作环境在后台执行繁重的工作（轮询），并使用包含队列消息 (refer to the docs for details). I have personally used the AWS push queues and have been happy with how easy they are. Note, that there are other push queue providers like Iron.io.
的 HTTP 请求简单地调用您的应用程序正如您提到的，您正在使用 PHP，Symfony 有 QPush Bundle，它处理传入的消息请求。您可以查看代码来推出自己的解决方案。