Вскоре после разворачивания AMQP сервера на выходных благополучно зависла виртуальная машина в которой жил RabbitMQ и… Было невесело и стало ясно, что пора воспользоваться кластером RabbitMQ.
Если вкратце, то кластер работает так: есть ноды, реплицирующие данные, есть memory-only ноды, на которых ничего не хранится. Клиент может подключиться к любой, но может получить редирект на другую ноду. Клиент должен уметь это отрабатывать, мне пришлось дописывать реализацию самому. При падении текущей ноды клиент должен сам переподключиться дальше. Если ему повезло, то он даже может сохранить auto_delete очереди, если успеет их законсумить. Однако я это не советую и лучше повторить процедуру подключения заново.
Итак, настройка кластера.
Всё было сделано четко по инструкции и сразу же возникли проблемы. Может я чего-то недопонял, но мой совет таков:
После этого все ерланги стартуют под нужными именами и вы спокойно сможете их склеить вместе.
Следующий этап — подготовка клиентов. RabbitMQ при коннекте сообщает список живых нод. Честно говоря, особого смысла в этом я не вижу. Сервер не говорит список дохлых нод а в процессе переподключения кто-то может и включиться обратно. Гораздо практичнее передать клиенту список всех узлов кластера, что бы клиент сам умел переподключаться между серверами.
Я использую две реализации клиентов AMQP: это самопереписанная rabbitmq-c — библиотека на языке C и прекрасный плагин для Ruby EventMachine: http://github.com/tmm1/amqp
Обе реализации пришлось допиливать, что бы они научились коннектиться к списку хостов. Например, мои доработки для ruby amqp можно найти у меня: http://github.com/maxlapshin/amqp
Итог таков: RabbitMQ легко заводится в кластере, доработка клиентов для стойкости к падению AMQP была несложной. Конструкция была проверена на живых пользователях с помощью kill -9 на одном из компьютеров, где вертятся RabbitMQ, все клиенты успешно переподключились.
xpost: http://habrahabr.ru/blogs/webdev/65710/
Предыдущие серии: