Давайте углубимся в конфигурацию кластера RabbitMQ и поймем плюсы и минусы различных режимов кластера. Цель этого обсуждения — помочь вам быстро понять, как работает кластер RabbitMQ, и выбрать режим, который лучше всего соответствует вашим потребностям. Ладно, особо нечего сказать. В RabbitMQ, даже если есть только один узел, сервис этого узла будет обрабатываться как кластер. Это означает, что одноузловые системы также соответствуют спецификациям кластерной архитектуры, обеспечивая согласованность и масштабируемость.
Существует два метода создания многоузловых кластеров: Обычный кластер и Зеркальный кластер (также называемый главным-подчиненным кластером).
Эта модель в полной мере использует присущие языку Erlang возможности кластеризации. В этом режиме кластера каждый узел использует одни и те же метаданные, такие как структура очереди, но сообщения не сохраняются избыточно, а существуют только на определенном узле. Когда потребителю необходимо использовать сообщение, если запрошенный узел не хранит требуемые данные, RabbitMQ временно передаст сообщение между узлами и перенесет данные из узла хранения в узел потребителя.
Очевидно, что этот режим кластера имеет определенные проблемы с надежностью сообщений. Когда узел выходит из строя, данные на этом узле не могут быть использованы и должны ждать восстановления узла, прежде чем обработка сможет продолжиться. Это может привести к тому, что потребитель не сможет правильно реагировать на уже использованные сообщения, а также может привести к повторному использованию сообщений после восстановления службы. Кроме того, если сообщение не сохранится, оно будет потеряно после перезапуска.
Кроме того, этот режим кластера не поддерживает высокую доступность. При сбое службы узла ее необходимо перезапустить вручную, чтобы обеспечить возможность нормального использования сообщений на узле. Поэтому этот режим подходит только для некоторых сценариев, не требующих высокой безопасности сообщений. При использовании этого режима потребителям следует попытаться подключиться к каждому узлу, чтобы уменьшить передачу сообщений в кластере.
Этот режим является официальным решением RabbitMQ HA (высокая доступность) в Обычном режиме. Улучшения были сделаны на основе режима кластера. Здание Обычный кластерпосле,Требуется дополнительная настройка и развертывание. Существенная разница в том, что,Этот режим активно синхронизирует сообщения между зеркальными узлами.,Вместо временной синхронизации, когда клиент получает сообщения.
В этом режиме главный узел (главный) и подчиненный узел (подчиненный) будут выбираться посредством алгоритма внутри кластера. В случае сбоя главного узла кластер автоматически выберет новый главный узел, чтобы обеспечить высокую доступность всего кластера.
Первый взгляд на Обычный кластер
Давайте еще раз посмотрим на зеркальный режим:
поэтому,Не существует универсального решения, подходящего всем,В конечном итоге кластерное решение должно определяться на основе каждого бизнес-требования. Например,В финансовых торговых системах или системах обработки данных в реальном времени.,Рекомендуется использовать режим зеркалирования высокой доступности. Но если пропускная способность ограничена и нет требований реального времени,Затем используйте значение по умолчанию Обычный кластер может быть более подходящим.
Благодаря этой статье мы получили более глубокое понимание режима кластера RabbitMQ, его преимуществ и недостатков. Будь то Обычный кластер или Зеркальный кластер, у них есть свои применимые сценарии и ограничения.
Обычный кластер использует возможности кластеризации языка Erlang, но при этом существуют определенные проблемы с надежностью сообщений и высокой доступностью; Кластер повышает надежность и высокую доступность сообщений за счет активной синхронизации сообщений, но может потреблять большую часть пропускной способности сети.
Поэтому при выборе кластерного решения необходимо всесторонне учитывать такие факторы, как бизнес-требования, производительность системы и ограничения ресурсов. Только наиболее подходящее решение может быть гибко выбрано в соответствии с реальной ситуацией, чтобы обеспечить стабильность и надежность системы.
Я участвую в последнем конкурсе эссе для специального учебного лагеря Tencent Technology Creation 2024. Приходите и разделите со мной приз!