Там ничего не нужно читать вообще - мой вопрос в тексте.
Я спрашивал, можно ли нормальным способом осуществлять доставку сообщений из очередей.
Речь про "кролика", ну или, может, какой-то альтернативный есть брокер, умеющий http.
Мне не нужна гипермасштабируемость, просто хочу уже просто развести все сервисы отправки и пр.
Ну и пока хотелось остаться на php.
"Нормальный способ" = доставка данных по HTTP на вебхук.
Петя делал "костыль" - "демонизированный" php скрипт, что, мне кажется, несколько костыльным способом.
Честно признаюсь, я с системой не сильно знаком, но тема показалась мне интересной, и я спросил коллегу который рубит в рэббит), и вот тебе решение, которое простое в реализации и правильное для php, и без домонизации:
1) Ставишь supervisord, это демон который запускает произвольные процессы (можно цифрой поставитm сколько надо штук) и перезапускает их когда они дохнут. Это стандартная практика для php и не только, для оборачивания демонов. На случай если они сдохнут
2) Пишешь тупой скрипт (воркер): забрать задание, выполнить, умереть.
И в конфиге supervisord ставишь 3-5 копий процесса. Дело в том, что вызов get_from_queue завершится только тогда когда в очереди сообщения либо есть либо появилось после. Тем самым брокер снимает с тебя ответственность по "пингу" очереди и минимизирует лейтенси между тем как его туда положили и тем что ты узнал об этом.
Получишь следующие бенефиты:
• У тебя ничего не упадет т.к. перезапустится
• память не потечет, т.к. процесс живет только на одно сообщение из очереди
• У тебя есть хоть какая-то конкурентность из коробки, если первое задание зависло, то как минимум 2 воркера еще работают
• На время перезапуска скрипта (а для реббита там время ппц какое ненулевое 150мс) маловероятно что остальные воркеры уже умерли тоже, и задание будет подхвачено с минимальным лейтенси
P.S. Первичная задача конечно немного адовая, т.к. AsyncCall есть во всех приличных фреймворках из коробки. Его и используют для сбора заданий из очереди.
#highload #очереди #RabbitMQ #уведомления