Вскоре после разворачивания AMQP сервера на выходных благополучно зависла виртуальная машина в которой жил RabbitMQ и… Было невесело и стало ясно, что пора воспользоваться кластером RabbitMQ.
Если вкратце, то кластер работает так: есть ноды, реплицирующие данные, есть memory-only ноды, на которых ничего не хранится. Клиент может подключиться к любой, но может получить редирект на другую ноду. Клиент должен уметь это отрабатывать, мне пришлось дописывать реализацию самому. При падении текущей ноды клиент должен сам переподключиться дальше. Если ему повезло, то он даже может сохранить auto_delete очереди, если успеет их законсумить. Однако я это не советую и лучше повторить процедуру подключения заново.
Итак, настройка кластера.
Мне потребовалось через RTMP рассылать данные в формате JSON по флешкам.
После прихода во флеш данные отправляются сразу в ExternalInterface.call:
ExternalInterface.call("juggernaut.receiveData", event.info.description);
В какой-то момент у меня начали валиться ошибки «в нигде» и «из
ниоткуда», которые
были видны только в Firebug-е. До receiveData дело не дошло.
Текст ошибки:
missing ) after argument list
Увидев вводный пост про AMQP решил поделиться своей практикой использования этого механизма.
Ещё задолго до начала внедрения AMQP у нас был полный зоопарк из различных обработчиков фоновых задач: delayed_job , starling + workling и т.п. Плюс к этому, ещё активно использовался HTTP ping между серверами и juggernaut для пуш-канала на браузер. Ах, ещё забыл брутальное оповещение по IP multicast.
Весь этот перечень страшных слов работает, но уж очень он разнообразен и обширен, решили урезать. Чего же общего между HTTP ping-ом и старлингом? Да то, что это всё сообщения от источника к подписчикам. AMPQ был выбран как общий транспорт для таких сообщений.