kza*_*zap 10 php message-queue gearman amazon-sqs supervisord
我试图围绕消息队列模型和我想在PHP应用程序中实现的作业:
我的目标是卸载需要发送到多个第三方API的消息/数据,因此访问它们不会减慢客户端的速度.因此,将数据发送到消息队列是理想的选择.
我考虑使用Gearman来保存MQ/Jobs,但我想使用像SQS或Rackspace Cloud Queues这样的Cloud Queue服务,所以我不必管理这些消息.
这是我认为我应该做的图表:
问题:
我的工作人员,将用PHP编写,他们都必须轮询云队列服务?特别是当你有很多工人时,这可能会变得昂贵.
我想也许有一个工人只是为了轮询队列,如果有消息,通知其他工人他们有工作,我只需要让这个1工人在线使用supervisord?这种轮询方法比使用可以通知的MQ更好吗?我应该如何每秒轮询一次MQ,或者每秒轮询一次?如果看到它放慢速度,那么增加投票工作人员?
我还考虑为所有消息设置一个队列,然后是工作人员监视,根据需要处理的位置将消息分发到其他云MQ,因为1个消息可能需要由2个差异工作者处理.
我还需要gearman管理我的工人supervisord吗?还是我可以用来上下旋转工人?
每当发送消息与轮询MQ时,向主工作人员发送通知是否更有效和更快?我假设我需要用来gearman通知我的主要工作者MQ有一条消息,所以它可以开始检查它.或者,如果我每秒有300条消息,这将产生300个作业来检查MQ?
基本上我怎么能尽可能有效和有效地检查MQ?
对我的架构的建议或更正?
我的建议基本上可以归结为:保持简单!
考虑到这一点,我的第一个建议是放弃DispatcherWorker. 根据我目前的理解,worker 的唯一目的是监听队列MAIN并将消息转发到不同的任务队列。您的应用程序应该负责将正确的消息排队到正确的队列(或主题)中。
我的工作人员会用 PHP 编写,他们都必须轮询云队列服务吗?这可能会变得昂贵,尤其是当你有很多工人时。
是的,天下没有免费的午餐。当然,您可以通过应用程序使用情况(当更多消息到达时增加轮询率)按天/周时间(如果您的用户在特定时间处于活动状态)等来调整和优化您的工作人员轮询率。请记住,工程成本可能很快就会高于未优化的轮询。
相反,您可以考虑推送队列(见下文)。
我在想也许有 1 个工作人员只是用于轮询队列,如果有消息,请通知其他工作人员他们有工作,我只需要使用supervisord 保持这 1 个工作人员在线?这种轮询方式是不是比使用可以通知的MQ更好呢?我应该如何轮询 MQ,每秒一次还是尽可能快地轮询?如果我发现投票速度放缓,然后增加投票工作人员?
这听起来太复杂了。通信是不可靠的,但是有可靠的消息队列。如果您不想丢失数据,请坚持使用消息队列并且不要发明自定义协议。
我还考虑为所有消息使用一个队列,然后由工作人员监控,根据需要处理的位置将消息分发到其他云 MQ,因为 1 条消息可能需要由 2 个差异工作人员处理。
正如已经提到的,应用程序应该根据需要将您的消息放入多个队列。这使事情变得简单和到位。
我是否仍然需要 gearman 来管理我的工人,或者我可以使用supervisord 来上下调整工人吗?
消息队列有很多,使用它们的方法也有很多。一般来说,如果您使用轮询队列,您需要自己让您的工作人员保持活动状态。但是,如果您使用推送队列,队列服务将调用您指定的端点。因此,您只需要确保您的员工有空即可。
基本上我怎样才能尽可能高效地检查 MQ?
这取决于您的业务要求和员工所做的工作。什么时间跨度是关键的?秒、分钟、小时、天?如果您使用工作人员发送电子邮件,则不会花费数小时,最好是几秒钟。每 3 秒或每 15 秒轮询一次(对于用户而言)有区别吗?
我的目标是卸载需要发送到多个第三方 API 的消息/数据,因此访问它们不会减慢客户端的速度。因此将数据发送到消息队列是理想的。我考虑过仅使用 Gearman 来保存 MQ/作业,但我想使用云队列服务,例如 SQS 或 Rackspace 云队列,这样我就不必管理消息。
事实上,您描述的场景非常适合消息队列。正如您提到的,您不想管理消息队列本身,也许您也不想管理工作人员?这就是推送队列出现的地方。
推送队列基本上会调用您的工作人员。例如,Amazon ElasticBeanstalk 工作线程环境在后台执行繁重的工作(轮询),并且只需使用包含队列消息的 HTTP 请求调用您的应用程序(有关详细信息,请参阅文档)。我亲自使用过 AWS 推送队列,并对它们的简单性感到满意。请注意,还有其他推送队列提供商,例如Iron.io。
正如您提到的,您正在使用 PHP, Symfony有QPush Bundle ,它可以处理传入的消息请求。您可以查看代码来推出您自己的解决方案。