Введите краткое описание своих изменений
(Обязательно)
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) Как поведет себя кластер в случае распада на несколько сегментов из-за проблем с сетью? А именно: если сегменты продолжат получать сообщения, то что будет происходит при соединении сегментов. Как будет синхронизироваться состояние очередей. Скорее всего в данном случае мы не сможем гарантировать то, что разделенные сегменты могут отдать одно и то же сообщение потребителям в итоге получив дублирование.
Брокер сообщений 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) Как поведет себя кластер в случае распада на несколько сегментов из-за проблем с сетью? А именно: если сегменты продолжат получать сообщения, то что будет происходит при соединении сегментов. Как будет синхронизироваться состояние очередей. Скорее всего в данном случае мы не сможем гарантировать то, что разделенные сегменты могут отдать одно и то же сообщение потребителям в итоге получив дублирование.