Все данные / состояние, необходимые для работы брокера RabbitMQ,
реплицируется по всем узлам. Исключением являются очереди сообщений,
которые по умолчанию находятся на одном узле, хотя они видны и
достижимы из всех узлов. Чтобы реплицировать очереди между узлами в
кластера, см. документацию по высокая доступность (примечание: это руководство
является обязательным условием для зеркалирования).
Узлы являются равноправными узлами. Некоторые распределенные системы имеют лидера и
следящие узлы. Как правило, это не так для RabbitMQ. Все узлы в
кластер RabbitMQ - равноправные узлы: в
Ядро RabbitMQ. Эта тема становится более нюансированной при зеркалировании очереди
и плагины принимаются во внимание, но для большинства целей и
цели, все узлы кластера должны считаться равными
2 - Отправляются ли в каждую очередь одинаковые сообщения для уменьшения ущерба в случае сбоя одной очереди?
По умолчанию содержимое очереди в кластере RabbitMQ находится
на одном узле (узле, на котором была объявлена очередь). Это
в отличие от обменов и привязок, которые всегда можно рассмотреть
быть на всех узлах. При желании очереди могут быть отражены через
несколько узлов.
Каждая зеркальная очередь состоит из одного мастера и одного или нескольких зеркал.
Мастер размещен на одном узле, обычно называемом главным узлом.
Каждая очередь имеет свой собственный главный узел. Все операции для данной очереди
сначала применяются к главному узлу очереди, а затем распространяются на
зеркала. Это включает постановку в очередь публикаций, доставку сообщений
потребителей, отслеживание подтверждений от потребителей и т. д.
Зеркальное отображение очереди подразумевает кластер узлов. Поэтому нет
рекомендуется для использования в глобальной сети (хотя, конечно, клиенты все еще могут
подключаться как можно ближе и так далеко, как нужно).
Сообщения, опубликованные в очереди, реплицируются на все зеркала.
Потребители подключены к мастеру независимо от того, какой узел они
соединяться с зеркалами, отбрасывая сообщения, которые были подтверждены
у мастера. Следовательно, зеркалирование очереди повышает доступность, но
не распределяет нагрузку по узлам (все участвующие узлы каждый
все работы).
Если узел, на котором размещен мастер очереди, выходит из строя, самое старое зеркало будет
повышен до нового мастера, пока он синхронизирован. Unsynchronised
зеркала также могут быть добавлены в зависимости от параметров зеркалирования очереди.
Существует несколько терминов, обычно используемых для определения основных и
вторичные реплики в распределенной системе. Это руководство обычно использует
«мастер» для ссылки на первичную копию очереди и «зеркало» для
вторичные реплики. Тем не менее, вы найдете здесь "раб" и
там. Это связано с тем, что инструменты RabbitMQ CLI исторически использовались
Термин «раб» относится к вторичным. Поэтому оба условия
в настоящее время используется взаимозаменяемо, но мы хотели бы в конечном итоге избавиться от
устаревшая терминология.