Действительная архитектура для очереди сообщений и рабочей системы в PHP?

Мои предложения в основном сводятся к: Держите это просто !

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

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

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

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

Вместо этого вы можете рассмотреть очереди push (см. Ниже).

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

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

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

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

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

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

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

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

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

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

В действительности сценарий, который вы описываете, подходит для очередей сообщений. Как вы упомянули, вы не хотите управлять самой очередью сообщений, может быть, вы тоже не хотите управлять рабочими? Здесь появляются точечные очереди .

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

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

Я бы порекомендовал другой маршрут, и это будет использование сокетов. ZMQ – это пример уже написанной библиотеки на основе сокетов. С сокетами вы можете создать Q и управлять тем, что делать с сообщениями по мере их поступления. Машина будет находиться в режиме ожидания и будет использовать минимальные ресурсы, ожидая появления сообщения.