Очередь сообщений. Можем ли мы инициировать события, когда сообщение попадает в очередь?
На работе мы обсуждаем, стоит ли реализовывать очередь сообщений для нашего PHP-приложения. В настоящее время мы смотрим на Apache ActiveMQ. Одна вещь, которая нам не совсем ясна, это то, возможно ли инициировать процесс на основе сообщения, поступающего в очередь.
Литература, которую мы до сих пор нашли, по-видимому, указывает на то, что очереди сообщений представляют собой механизм, основанный на извлечении: процесс запускается регулярно (как демон или cron) и извлекает свои входящие сообщения из очереди. Можно ли превратить это в толкающий механизм? То есть есть ли способ, чтобы Очередь сообщений фактически инициировала HTTP-запрос (или процесс) при получении сообщения? Одна из найденных нами опций - это модель публикации / подписки, но для этого необходимо запустить наше PHP-приложение в бесконечном цикле, чтобы поддерживать открытое (TCP) соединение с экземпляром ActiveMQ, что выглядит как клудж.
Любой вклад будет высоко ценится.
3 ответа
Очевидное решение - позволить издателю инициировать HTTP-запрос сразу после сохранения сообщения, но возникает вопрос: почему тогда вы используете очередь сообщений?
Наличие группы потребителей, слушающих очередь и выполняющих свою работу по мере поступления сообщений, - это не проблема, это хороший, масштабируемый дизайн. (Хотя я согласен, что запуск процесса PHP в бесконечном цикле имеет свои недостатки.)
Почему вы выбрали очередь сообщений, а не, скажем, базу данных, в которой хранятся сообщения? "Производитель" может сохранить сообщение как строку в таблице, а затем вызвать "потребителя" с помощью PK сообщения.
Ваша концепция разработки приложения для мониторинга очереди - это отраслевой способ запуска внешнего приложения. Взгляните на IBM Websphere "Trigger Monitor Applications". В их реализации у вас может быть несколько мониторов триггера для запуска приложений, которые обрабатывают сообщения в очереди, поэтому он очень хорошо масштабируется при запуске монитора триггера на сервере, на котором установлены приложения (и если вы разрабатываете для масштабируемости, вы должны иметь возможность иметь несколько серверов приложений, если это необходимо).
Рассмотрите возможность создания маршрута Camel, который извлекает сообщения из очереди (компонент JMS) и пересылает их в конечную точку HTTP (компонент HTTP). Вы можете даже решить разместить хост Camel в процессе посредника ActiveMQ - создавая своего рода интеллектуального посредника маршрутизации. ActiveMQ облегчает эту задачу, объединяя библиотеки Camel Core в дистрибутив ActiveMQ.
Вот недавний соответствующий / связанный пост: