Как работает кластеризация в RabbitMQ?
Что проверяют
Понимаете ли вы, что именно реплицируется в кластере RabbitMQ, а что нет, и что происходит с сообщениями при падении узла. Следом обычно спрашивают про типы очередей и про то, как Python-приложение переживает переключение.
Как отвечать
Кластер это несколько узлов с общим Erlang cookie в одной сети с низкой задержкой. Разделите две вещи: метаданные и сообщения.
- метаданные: пользователи, vhost, exchange, привязки, политики и описания очередей есть на всех узлах. Хранилище метаданных в ветке 4.x переходит с Mnesia на Khepri, построенный на Raft;
- классические очереди: сообщения живут на одном узле, остальные только перенаправляют к нему трафик. Упал узел, и очередь недоступна, пока он не вернётся;
- quorum queues: реплицированный тип очереди на Raft, лидер и последователи на разных узлах. Работают, пока жив кворум, поэтому узлов нечётное число: из трёх можно потерять один. Объявляются аргументом
x-queue-type: quorum; - streams: тоже реплицируются, это журнал с повторным чтением;
- зеркалирование классических очередей: политика
ha-modeудалена в RabbitMQ 4.0, отказоустойчивость теперь дают только quorum queues и streams.
Одна очередь не масштабируется добавлением узлов: её обслуживает один лидер. Пропускная способность растёт, когда очередей много и их лидеры распределены.
Сборка: на новом узле rabbitmqctl stop_app, rabbitmqctl join_cluster rabbit@node1, rabbitmqctl start_app, проверка через rabbitmqctl cluster_status. В Kubernetes для этого есть peer discovery и оператор.
Со стороны Python: aio-pika с connect_robust переподключается сам, в pika переподключение пишут сами, указав несколько узлов или балансировщик. Чтобы сообщение не пропало, включают publisher confirms: брокер подтверждает публикацию, когда её записал кворум.
Где спотыкаются
Считают, что кластер сам копирует все сообщения. Без quorum queues падение узла отрезает его классические очереди.
Рассказывают про mirrored queues как про актуальный механизм. Для 4.x это удалённая функция.
Растягивают кластер между дата-центрами. Кластер плохо переносит задержки и разрывы сети, площадки связывают плагинами federation и shovel.