Блог

У меня следующая ситуация:

Два раза в день в течение примерно 1 часа мы получаем огромный поток сообщений, которые в настоящее время проходят через RabbitMQ. Текущий кроличий кластер с 3 узлами не может обрабатывать всплески, в противном случае работает без сбоев. В настоящее время он настроен на чистые экземпляры EC2. Тип экземпляра — текущий t3.medium, что очень мало, если не считать остальных 22 часов в день, когда мы получаем ~ 5 сообщений в секунду. В настоящее время он также настроен на ha-mode= all.

После довольно длительного и показательного чтения в документах rabbitmq я решил просто попробовать настроить кластер ECS EC2 и масштабировать его при увеличении нагрузки на процессор. Итак, создайте на нем службу и добавьте эту службу в обнаружение службы. Например discovery.rabbitmq . Если есть три экземпляра, то все они будут работать с одним и тем же именем, но будут разрешены для всех трех IP-адресов. Присоединение к кластеру будет работать на основе этого:

Это будет часть rabbitmq.conf:

 cluster_formation.peer_discovery_backend = dns

# the backend can also be specified using its module name
# cluster_formation.peer_discovery_backend = rabbit_peer_discovery_dns

cluster_formation.dns.hostname = discovery.rabbitmq
 

Я использую политику ha_mode=exact с 2 репликами.

Наши обмены и очереди создаются вручную заранее по причинам, которые я не могу обсуждать дальше, но это данность. Они не могут быть удалены, и они не будут воссозданы на лету. У нас есть 3 обмена с каждыми 4 очередями.

Итак, идея: во время высокой нагрузки — добавляйте больше экземпляров, во время отсутствия нагрузки запускайте с тремя экземплярами (или даже меньше).

Настройка с уменьшением / увеличением масштаба работала нормально, пока я не начал использовать инструмент сравнительного анализа и не обнаружил, что очереди всегда создаются на одном узле, который становится хозяином очереди. Это нормально, учитывая, что инструмент сравнительного анализа подключен к одному узлу. Проблема в том, что после масштабирования / уменьшения наши созданные вручную очереди не перемещаются на другие узлы. Это также соответствует тому, что я прочитал на странице выпуска rabbit 3.8:

Одной из проблем при выполнении последовательного обновления до серверов кластера RabbitMQ было то, что мастера очереди в конечном итоге будут сосредоточены на одном или двух серверах. Новая команда перебалансировки автоматически перебалансирует мастера по всему кластеру.

Вот проблемы, с которыми я столкнулся, я ищу совета:

1. Если я правильно интерпретирую документы, масштабирование вообще не поможет, потому что эти узлы будут сидеть там на холостом ходу, пока кто-нибудь не вызовет вручную rabbitmq-queues rebalance all .
2. Каков был бы предпочтительный способ масштабирования?