Запуск PHP из ActiveMQ

Question

Справочная информация: Наша текущая система включает в себя две службы (одну написанную на Java, другую на PHP), которые взаимодействуют друг с другом с помощью HTTP-обратных вызовов. Мы хотим перейти от HTTP-обратных вызовов к архитектуре на основе сообщений, используя ActiveMQ (или, если необходимо, другую). Мы, вероятно, будем использовать STOMP для связи между ними. В конце концов, PHP-сервис будет переписан на Java, но это не является частью этого проекта.

Вопрос: Как система ActiveMQ может уведомить PHP о том, что новое сообщение было выложено в очередь, что система PHP подписался на? В текущей системе обратный вызов по своей сути вызывает PHP и запускает его. Это уходит с архитектурой на основе сообщений.

Возможные решения:

• Крон регулярно называет PHP скрипт, который проверяет наличие новых сообщений. Тьфу.
• Долгосрочный PHP-процесс, который зацикливается и спит и проверяет наличие новых сообщений. меньше yuck?
• ActiveMQ вызывает скрипт PHP при отправке нового сообщения. хорошо, как?
• ??

Answer 1

Оформить заявку Camel. Он может работать внутри ActiveMQ или сам по себе. Camel создает «маршруты» для сообщений. В этом случае я бы предположил, что вы оставите URL-адрес обратного вызова PHP как есть, и настройте маршрут в Camel, который принимает сообщения из очереди и отправляет их на URL обратного вызова. Затем вы можете использовать Stomp в PHP для отправки сообщений в ActiveMQ. Ваш Java-код может просто использовать JMS для входящих и исходящих сообщений.

Answer 2

У вас есть ActiveMQ для выполнения команд оболочки? Если это так, просто запустите ActiveMQ скрипт PHP через командную строку всякий раз, когда есть новое сообщение для обработки. Это избавляет вас от выполнения заданий cron и от длительной петли PHP.

Answer 3

Вопрос: Как система ActiveMQ уведомляет PHP о том, что новое сообщение отправлено в очередь, на которую подписана система PHP? В текущей системе обратный вызов по своей сути вызывает PHP и запускает его. Это уходит с архитектурой на основе сообщений.

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

Answer 4

Я думаю, что проблема, которую они пытаются решить, заключается в том, что стек LAMP (из которого PHP является частью) по сути связан с механизмом запроса/ответа, который на него накладывает HTTP-протокол, поэтому с помощью Потребителя (который проверяет очередь ActiveMQ), написанная на PHP, работоспособна, но время жизни процессов естественно ограничено любым тайм-аутом в протоколе HTTP.решение является одним из:

1 - Не запускайте подписчика PHP внутри apache/HTTP, и в результате вы можете сделать set_time_limit (0) и запустить php Subscriber навсегда (пока он не сработает в любом случае), ИЛИ

2 - Поймите, что Абонент действительно выполняет «периодические» проверки с большим количеством ничего между ними, поэтому вместо while (1) {do_queue_stuff(); спать(); } вы удаляете спящий режим, удаляете цикл while и вызываете его повторно из Cron или аналогичного.

У каждого есть свои преимущества, но оба одинаково хороши, ЕСЛИ частота cron() достаточно подстраивается. Мой Cron ограничен работой каждую минуту, что не очень часто, поэтому мне пришлось бы сделать комбинацию из двух следующих: , вызываемых из cron каждую минуту:

time = what_minute_is_it(); while (what_minute_is_it() == время) { do_queue_stuff(); сон (1); }

Я думаю, что люди могут последовать за тем, чтобы система ActiveMQ «намекала» на систему PHP Consumer, что в очереди, которая нуждается в обработке, может быть материал, и, как результат, сохранить во всей этой очереди обработка start/stop/sleep/etc, если на самом деле нечего делать. Кажется, верблюд - это способ сделать это.