Введите краткое описание своих изменений
(Обязательно)
Minor changes are by default collapsed in the page history.
No changes
The page does not exist yet.
Failed to load changes
Версия от на
Leave Collaboration
Are you sure you want to leave the realtime collaboration and continue editing alone? The changes you save while editing alone will lead to merge conflicts with the changes auto-saved by the realtime editing session.
RabbitMQ. Часть 1. Introduction. Erlang, AMQP и RPC RabbitMQ. Часть 2. Разбираемся с Exchanges RabbitMQ. Часть 3. Разбираемся с Queues и Bindings https://habr.com/ru/post/489086/
В RabbitMq есть возможности для создания кластеров, состоящих из нескольких узлов. По умолчанию очереди не реплицируются между нодами кластера и в случае выхода из строя ноды с очередью, очередь будет потеряна.
Также существует механизм зеркалирования, который позволяет производить репликацию очередей. В таком случае для очереди одна нода выступает в роли мастера, остальные в роли подчиненного. Чтение и запись будут проходить через мастер ноду, а от нее распространяться на подчиненные ноды. В случае выхода из строя мастер ноды, одна из подчиненных нод берет на себя роль мастер ноды. Если упавшая нода оживает, то она возвращается в кластер, но в роли подчиненной ноды. Зеркалирование можно происходит, как на все ноды в кластере, так и на несколько (задается количеством реплик или указанием конкретных узлов кластера). При зеркалировании отправка сообщения с клиента считается успешно завершенной только после того, как мастер нода очереди распространило реплики сообщения на все подчиненные ноды репликации. При обращении к подчиненной ноде для выполнения отправки или потребления сообщения, подчиненная нода выполняет обращение к мастер ноде очереди. (Поэтому, по возможности, имеет смысл подключаться к ноде, выступающей в роде мастер-ноды для конкретной очереди)
Вопросы: 1) Как поведет себя кластер в случае распада на несколько сегментов из-за проблем с сетью? А именно: если сегменты продолжат получать сообщения, то что будет происходит при соединении сегментов. Как будет синхронизироваться состояние очередей. Скорее всего в данном случае может возникнуть ситуация, при которой разделенные сегменты могут отдать одно и то же сообщение потребителям в итоге получив дублирование. Clustering and Network Partitions https://www.rabbitmq.com/partitions.html
Примечание: Существуют и альтернативные методики синхронизации основанные на 1) плагине федераций 2) плагине лопата. (клиент-потребитель, запущенный на стороне брокера и автоматически пересылающий сообщения из одной очереди в другие) 3) явном управлении со стороны клиентов очереди, отправка сообщения сразу на несколько очередей/брокеров.
Брокер сообщений RabbitMQ: Часть 1. Установка и настройка отказоустойчевого кластера
https://www.youtube.com/watch?v=XiyXOMYoXAw
https://www.youtube.com/watch?v=1UfVZVr39Cg
RabbitMQ Retries — The Full Story
https://engineering.nanit.com/rabbitmq-retries-the-full-story-ca4cc6c5b493
RabbitMQ. Часть 1. Introduction. Erlang, AMQP и RPC
RabbitMQ. Часть 2. Разбираемся с Exchanges
RabbitMQ. Часть 3. Разбираемся с Queues и Bindings
https://habr.com/ru/post/489086/
В RabbitMq есть возможности для создания кластеров, состоящих из нескольких узлов.
По умолчанию очереди не реплицируются между нодами кластера и в случае выхода из строя ноды с очередью, очередь будет потеряна.
Также существует механизм зеркалирования, который позволяет производить репликацию очередей. В таком случае для очереди одна нода выступает в роли мастера, остальные в роли подчиненного.
Чтение и запись будут проходить через мастер ноду, а от нее распространяться на подчиненные ноды. В случае выхода из строя мастер ноды, одна из подчиненных нод берет на себя роль мастер ноды. Если упавшая нода оживает, то она возвращается в кластер, но в роли подчиненной ноды.
Зеркалирование можно происходит, как на все ноды в кластере, так и на несколько (задается количеством реплик или указанием конкретных узлов кластера).
При зеркалировании отправка сообщения с клиента считается успешно завершенной только после того, как мастер нода очереди распространило реплики сообщения на все подчиненные ноды репликации. При обращении к подчиненной ноде для выполнения отправки или потребления сообщения, подчиненная нода выполняет обращение к мастер ноде очереди. (Поэтому, по возможности, имеет смысл подключаться к ноде, выступающей в роде мастер-ноды для конкретной очереди)
Вопросы:
1) Как поведет себя кластер в случае распада на несколько сегментов из-за проблем с сетью? А именно: если сегменты продолжат получать сообщения, то что будет происходит при соединении сегментов. Как будет синхронизироваться состояние очередей. Скорее всего в данном случае может возникнуть ситуация, при которой разделенные сегменты могут отдать одно и то же сообщение потребителям в итоге получив дублирование.
Clustering and Network Partitions
https://www.rabbitmq.com/partitions.html
Примечание:
Существуют и альтернативные методики синхронизации основанные на
1) плагине федераций
2) плагине лопата. (клиент-потребитель, запущенный на стороне брокера и автоматически пересылающий сообщения из одной очереди в другие)
3) явном управлении со стороны клиентов очереди, отправка сообщения сразу на несколько очередей/брокеров.