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

Question

На работе мы обсуждаем, стоит ли реализовывать очередь сообщений для нашего PHP-приложения. В настоящее время мы смотрим на Apache ActiveMQ. Мы не совсем понимаем, есть ли возможность инициировать процесс на основе сообщения, поступающего в очередь.

Литература, которую мы до сих пор обнаружили, по-видимому, указывает на то, что очереди сообщений представляют собой механизм, основанный на извлечении: процесс выполняется регулярно (как демон или cron) и извлекает входящие сообщения из очереди. Можно ли превратить это в толкающий механизм? То есть есть ли способ, чтобы Очередь сообщений фактически инициировала HTTP-запрос (или процесс) при получении сообщения? Одна из найденных нами опций - это модель публикации / подписки, но для этого требуется, чтобы наше PHP-приложение работало в бесконечном цикле для поддержания открытого (TCP) соединения с экземпляром ActiveMQ, что выглядит как отчасти.

Любой вклад будет высоко ценится.

Answer 1

Рассмотрите возможность создания маршрута Camel, который извлекает сообщения из очереди (компонент JMS) и пересылает в конечную точку HTTP (компонент HTTP). Вы можете даже решить разместить хост Camel в процессе брокера ActiveMQ - создавая своего рода интеллектуальный брокер маршрутизации. ActiveMQ облегчает эту задачу, объединяя библиотеки Camel Core в дистрибутив ActiveMQ.

Вот недавний соответствующий / связанный пост:

Сообщение HTTP из ActiveMQ с использованием Camel

Answer 2

Ваша концепция разработки приложения для мониторинга очереди - это отраслевой способ запуска внешнего приложения. Взгляните на IBM Websphere "Trigger Monitor Applications". В их реализации у вас может быть несколько мониторов триггера для запуска приложений, которые обрабатывают сообщения в очереди, поэтому он очень хорошо масштабируется при запуске монитора триггера на сервере, на котором установлены приложения (и если вы разрабатываете для масштабируемости, вы должны иметь возможность иметь несколько серверов приложений, если это необходимо).

Answer 3

Очевидное решение - позволить издателю инициировать HTTP-запрос сразу после сохранения сообщения, но возникает вопрос: почему тогда вы используете очередь сообщений?

Наличие группы потребителей, слушающих очередь и выполняющих свою работу по мере поступления сообщений, не является препятствием, это хороший, масштабируемый дизайн. (Хотя я согласен, что запуск процесса PHP в бесконечном цикле имеет свои недостатки.)

Почему вы выбрали очередь сообщений, а не, скажем, базу данных, в которой хранятся сообщения? «Производитель» может сохранить сообщение как строку в таблице, а затем вызвать «потребителя» с помощью PK сообщения.