Как организовать работу PHP и RabbitMQ?

Question

[streich]

Необходимо при возникновении определенного события отправлять запросы на обработку данных на сторонний сервер, который периодически "отваливается", а кроме того имеет ограничение - принимать в минуту не более 5 запросов. Событий может возникать больше 5 в минуту, поэтому было принято решение использовать очереди (RabbitMQ).
Большинство примеров использования очередей сводится к банальному:

• запустил в одной консоли скрипт, в котором установил соединение, задал точку обмена, очередь и отправил сообщение "Hello World!"
  
• запустил во второй конcоли скрипт, в котором также установил соединение, задал точку обмена, очередь, подписался на сообщения этой очереди и задал бесконечный цикл:

  while ($channel->is_consuming()) {
  	      $channel->wait();
  }

  
  

1. Как ограничить количество прочтенных сообщений получателем, чтобы их было не более 5 в минуту, чтобы соблюсти наложенное ограничение сторонним сервером?
   
2. Как несмотря на наличие ограничения на количество читаемых сообщений в минуту, сделать бесконечно ожидающего слушателя? Держать на проде постоянно запущенный в консоли скрипт - это плохое решение.
   
3. Как быть с получением и обработкой сообщений, если сторонний сервер вообще на какое-то время "отвалился"?
   

Comments

[Дмитрий]

1. Где-то хранить данные по владельцам сообщений и в случае оверквоты - откладывать на минуту. Какой нибудь редис вполне покатит.
2. Не понял? Вы не хотите держать демона разгребающего очередь? А что вы хотите?
3. Откладывать задачу на какое то время - если задача обязательно должна быть обработана. Или выкидывать ее в ведро, если похрен

[streich]

Дмитрий, Можете уточнить подробнее:

1. Не совсем понятна Ваша идея с Redis в сочетании с тем, что сообщения-задания данные будут на Rabbitе храниться
   
2. Демонов на PHP не приходилось реализовывать. Насколько они стабильно работают и не отваливаются? Была идея по крону запускать скрипт получателя, потом спустя время завершать его, а потом сразу снова запускать. Но такая идея выглядит очень костыльной.
   

[Дмитрий]

streich,
1. Ну а что будет знать сообщение о том сколько задач от этого пользователя за последнюю минут обработалось? Ничего. Она собственно и не может знать - потому что этап постановки задачи != этапу обработки задачи.
Значит скрипт который обрабатывает джобы из очереди после каждой обработки должен куда то запомнить сколько задач от этого пользователя он за последнюю минуту обработал.
2. Ну смотря как напишите. Если нормально напишите - будет нормально работать.
Если вы хотите по крону - то нахрена вам очередь вообще? Почему не обычная таблица в базе данных?

[streich]

Дмитрий,
2. Очередь нужна за тем, что в будущем нужно будет делать и другие операции, для которых нужна очередь: например, нотификация юзеров. И использовать БД в таких случаях будет слишком тяжеловесно. Поэтому механизм хочется отладить сейчас, чтобы дальше его использовать и в других задачах (более классических).

[Дмитрий]

streich, ну какой то особо критичной выгоды от работы с очередью по крону я не вижу.