Допустимая архитектура для очереди сообщений & amp; Рабочая система в PHP?

Мои предложения в основном сводятся к: Будь проще!

Имея это в виду, мое первое предложение — отказаться от DispatcherWorker, Исходя из моего нынешнего понимания, единственная цель работника состоит в том, чтобы слушать MAIN очереди и пересылать сообщения в разные очереди задач. Ваше приложение должно позаботиться о постановке правильного сообщения в нужную очередь (или тему).

Отвечая на ваши вопросы:

Мои работники, будут ли написаны на PHP все они должны опрашивать службу облачной очереди? это может дорого обойтись, особенно если у вас много работников.

Да, нет бесплатного обеда. Конечно, вы можете адаптировать и оптимизировать частоту опроса своего рабочего в зависимости от использования приложения (когда поступает больше сообщений, увеличивают частоту опроса) по времени дня / недели (если ваши пользователи активны в определенное время) и так далее. Имейте в виду, что инженерные расходы могут вскоре превысить неоптимизированный опрос.

Вместо этого вы могли бы рассмотреть push-очереди (увидеть ниже).

Я подумал, может быть, есть 1 работник только для того, чтобы опрашивать очередь, и если есть сообщения, сообщите другим работникам, что у них есть работа, я просто должен держать этого 1 работника в сети, используя Supervisord, возможно? этот метод опроса лучше, чем использование MQ, который может уведомить? Как я должен опрашивать MQ, раз в секунду или так быстро, как он может опрашивать? а затем увеличить число избирателей, если я увижу, что это замедляется?

Это звучит слишком сложно. Связь ненадежна, однако существуют надежные очереди сообщений. Если вы не хотите терять данные, придерживайтесь очередей сообщений и не изобретайте собственные протоколы.

Я также думал о том, чтобы иметь единую очередь для всех сообщений, а затем рабочий мониторинг, который распределяет сообщения в другие облачные MQ в зависимости от того, где они должны быть обработаны, так как 1 сообщение, возможно, должно быть обработано двумя работниками diff.

Как уже упоминалось, приложение должно ставить ваше сообщение в очередь по мере необходимости. Это держит вещи простыми и на месте.

Буду ли я все еще нуждаться в механизме, чтобы управлять своими работниками, или я могу просто использовать супервизор, чтобы крутить рабочих вверх и вниз?

Существует так много очередей сообщений и даже больше способов их использования. В общем, если вы используете очереди на опрос вам нужно будет поддерживать жизнь своих работников самостоятельно. Однако, если вы используете push-очереди, служба очереди вызовет указанную вами конечную точку. Таким образом, вам просто нужно убедиться, что ваши работники доступны.

В основном, как я могу проверить MQ максимально эффективно и максимально эффективно?

Это зависит от требований вашего бизнеса и работы, которую выполняют ваши работники. Какие промежутки времени являются критическими? Секунды, минуты, часы, дни? Если вы используете рабочих для отправки электронных писем, это не должно занять несколько часов, в идеале пару секунд. Есть ли разница (для пользователя) между опросом каждые 3 секунды или каждые 15 секунд?

Решение вашей проблемы (с очередями push):

Моя цель — разгрузить сообщения / данные, которые необходимо отправить нескольким сторонним API, поэтому доступ к ним не замедляет работу клиента. Поэтому отправка данных в очередь сообщений является идеальной. Я решил использовать только Gearman для хранения MQ / Jobs, но я хотел использовать службу Cloud Queue, такую ​​как SQS или Rackspace Cloud Queues, поэтому мне не пришлось бы управлять сообщениями.

Действительно, сценарий, который вы описываете, хорошо подходит для очередей сообщений.
Как вы упомянули, вы не хотите управлять самой очередью сообщений, может быть, вы не хотите управлять и рабочими? Это где push-очереди поп в.

Push-очереди в основном вызов твой работник. Например, рабочие среды Amazon ElasticBeanstalk выполняют тяжелую работу (опрос) в фоновом режиме и просто вызывают ваше приложение с помощью HTTP-запроса, содержащего сообщение очереди (обратитесь к документации для деталей). Я лично пользовался очередями push-уведомлений AWS и был доволен их легкостью. Обратите внимание, что есть другие поставщики push-очередей, такие как Iron.io.

Как вы уже упоминали, вы используете PHP, есть QPush Bundle для Symfony, который обрабатывает запросы на входящие сообщения. Вы можете взглянуть на код, чтобы развернуть собственное решение.