4. Кластеры и High Availability

В этой теме — кластер RabbitMQ, отказоустойчивость и поведение при сбоях: classic vs quorum очереди, (устаревшее) mirroring, сетевые разделения (network partitions), лидерство и практики эксплуатации в production. Цель — понимать, что будет при падении ноды и как избежать split-brain‑сюрпризов.

Определения

Термин	Определение
RabbitMQ cluster	Набор нод RabbitMQ, объединённых общим состоянием (metadata) и коммуникацией Erlang; используется для масштабирования и HA.
Classic queue	«Классическая» очередь (историческая реализация). Может быть в single‑node виде или в mirrored (quorum‑не‑Raft) варианте (mirroring).
Quorum queue	Очередь на основе Raft‑репликации: один лидер + реплики; лучшее поведение при сбоях, рекомендовано для HA в production.
Leader election	Выбор лидера (в quorum) для принятия записей; при отказе лидера происходит переизбрание.
Network partition	Ситуация, когда кластер «разрезан» сетью: ноды не видят друг друга (split network).
Split-brain	Когда части системы продолжают работать независимо, принимая конфликтующие изменения; в брокерах это особенно опасно для метаданных/очередей.

Когда нужен кластер (и когда не нужен)

Кластер имеет смысл, когда:

нужен HA (пережить падение ноды без простоя на уровне очередей);
нужен больший throughput по подключениям/каналам;
нужно распределение нагрузки (несколько нод принимают соединения).

Не делать кластер «просто потому что можно»:

усложняется эксплуатация (обновления, сетевые разделения, диски);
требует дисциплины в настройках, мониторинге и тестировании отказов.

Classic vs Quorum queues (production выбор)

Что выбирать

Quorum queues — default выбор для критичных очередей в production (HA и предсказуемость).
Classic queues — подходят для простых сценариев или когда HA очередей не нужна (и вы готовы к падению одной ноды как к остановке очереди).

Почему quorum обычно лучше

Raft даёт понятную модель лидер/реплики и поведение при отказах.
Меньше «магии» вокруг split-brain и сетевых проблем.

Важный нюанс

Quorum — это не «бесплатная» репликация:

больше I/O и CPU, чем у single classic;
нужен правильный размер диска и мониторинг latency.

Network partitions: как кластер реагирует на “разрез сети”

При partition часть нод может потерять связь с остальными. Важно заранее выбрать стратегию, чтобы кластер не жил «двумя жизнями».

Ключевые подходы (на уровне концепции):

Pause minority: меньшинство останавливается, чтобы не принимать конфликтующие изменения.
Autoheal: попытка автоматически восстановиться после исчезновения partition (может быть опасно без понимания последствий).

Best practice:

в production выбирать поведение, которое предотвращает split-brain (обычно “останавливать меньшинство” по смыслу);
тестировать на стенде: “разрезали сеть” → “что видят клиенты” → “как быстро восстановились”.

Практика: поднять кластер из 3 нод (Docker Compose)

Ниже — минимальная демонстрационная схема (для обучения). В production обычно разворачивают в Kubernetes (operator/Helm) или на VM с конфигурационным менеджментом.

# docker-compose.yaml (упрощённо; демонстрация принципа)
services:
  rmq1:
    image: rabbitmq:3-management
    hostname: rmq1
    environment:
      RABBITMQ_ERLANG_COOKIE: "same-cookie-for-all"
    ports: ["15672:15672", "5672:5672"]
  rmq2:
    image: rabbitmq:3-management
    hostname: rmq2
    environment:
      RABBITMQ_ERLANG_COOKIE: "same-cookie-for-all"
  rmq3:
    image: rabbitmq:3-management
    hostname: rmq3
    environment:
      RABBITMQ_ERLANG_COOKIE: "same-cookie-for-all"

Комментарии:

Erlang cookie должен быть одинаковым для всех нод.
В production нужны persistent volumes для данных и настройки ресурсов/лимитов.

Дальше ноды объединяются в cluster командами rabbitmqctl (порядок зависит от окружения). Это намеренно оставлено как упражнение, потому что в production чаще используются готовые инструменты (Helm/operator), а важно — понимать принципы.

Проверка и диагностика кластера (CLI)

# Статус ноды
rabbitmqctl status

# Состояние кластера (какие ноды входят)
rabbitmqctl cluster_status

# Обзор очередей
rabbitmqctl list_queues name durable messages_ready messages_unacknowledged consumers

Production best practices (HA)

Топология и инфраструктура

3 ноды минимум для кластера (кворум); 5 — если нужен больший запас по отказам (по стоимости/сложности).
Разносить ноды по разным failure domain (AZ/стойки), но помнить про latency сети и диска.
Следить за disk I/O: для quorum очередей диск — критичен.

Очереди и настройки

Для критичных потоков использовать quorum queues.
Не смешивать «всё подряд» в одном vhost: разделять по окружениям и по нагрузке.
Делать DLQ обязательным элементом дизайна (иначе “плохие сообщения” будут ломать поток бесконечно).

Обновления и отказоустойчивость

Обновлять ноды по одной (rolling), контролируя метрики и состояние кластера.
Тестировать «убили ноду» регулярно на staging: что происходит с publish/consume, сколько времени восстановление.

Мониторинг и алерты

Алерты: memory alarm, disk alarm, рост backlog, отсутствие consumer’ов.
В quorum очередях следить за задержками и состоянием реплик (как минимум через management UI + exporter).