Изменения документа Механизмы

Редактировал(а) Alexandr Fokin 2023/12/16 14:13

От версии < 1.3 >
отредактировано Alexandr Fokin
на 2022/11/15 22:04
К версии 1.1 >
отредактировано Alexandr Fokin
на 2022/10/28 15:09
>
Изменить комментарий: К данной версии нет комментариев

Комментарий

Подробности

Свойства страницы
Содержимое
... ... @@ -1,31 +1,0 @@
1 -|(% style="width:121px" %)Кластер|(% style="width:1360px" %)(((
2 -Брокер сообщений RabbitMQ: Часть 1. Установка и настройка отказоустойчевого кластера
3 -[[https:~~/~~/www.youtube.com/watch?v=XiyXOMYoXAw>>url:https://www.youtube.com/watch?v=XiyXOMYoXAw]]
4 -[[https:~~/~~/www.youtube.com/watch?v=1UfVZVr39Cg>>url:https://www.youtube.com/watch?v=1UfVZVr39Cg]]
5 -
6 -----
7 -
8 -В RabbitMq есть возможности для создания [[Кластер>>doc:Разработка.Базы данных.Концепции.Кластер.WebHome]], состоящих из нескольких узлов.
9 -По умолчанию очереди не реплицируются между нодами кластера и в случае выхода из строя ноды с очередью, очередь будет потеряна.
10 -
11 -Также существует механизм зеркалирования, который позволяет производить репликацию очередей. В таком случае для очереди одна нода выступает в роли мастера, остальные в роли подчиненного.
12 -Чтение и запись будут проходить через мастер ноду, а от нее распространяться на подчиненные ноды. В случае выхода из строя мастер ноды, одна из подчиненных нод берет на себя роль мастер ноды. Если упавшая нода оживает, то она возвращается в кластер, но в роли подчиненной ноды.
13 -Зеркалирование можно происходит, как на все ноды в кластере, так и на несколько (задается количеством реплик или указанием конкретных узлов кластера).
14 -При зеркалировании отправка сообщения с клиента считается успешно завершенной только после того, как мастер нода очереди распространило реплики сообщения на все подчиненные ноды репликации. При обращении к подчиненной ноде для выполнения отправки или потребления сообщения, подчиненная нода выполняет обращение к мастер ноде очереди. (Поэтому, по возможности, имеет смысл подключаться к ноде, выступающей в роде мастер-ноды для конкретной очереди)
15 -
16 -Вопросы:
17 -1) Как поведет себя кластер в случае распада на несколько сегментов из-за проблем с сетью? А именно: если сегменты продолжат получать сообщения, то что будет происходит при соединении сегментов. Как будет синхронизироваться состояние очередей. Скорее всего в данном случае может возникнуть ситуация, при которой разделенные сегменты могут отдать одно и то же сообщение потребителям в итоге получив дублирование.
18 -Clustering and Network Partitions
19 -[[https:~~/~~/www.rabbitmq.com/partitions.html>>url:https://www.rabbitmq.com/partitions.html]]
20 -
21 -Примечание:
22 -Существуют и альтернативные методики синхронизации основанные на
23 -1) плагин федераций
24 -2) плагин лопата. (клиент-потребитель, запущенный на стороне брокера и автоматически пересылающий сообщения из одной очереди в другие)
25 -3) явном управлении со стороны клиентов очереди, отправка сообщения сразу на несколько очередей/брокеров.
26 -)))
27 -|(% style="width:121px" %)Retry policies|(% style="width:1360px" %)RabbitMQ Retries — The Full Story
28 -[[https:~~/~~/engineering.nanit.com/rabbitmq-retries-the-full-story-ca4cc6c5b493>>url:https://engineering.nanit.com/rabbitmq-retries-the-full-story-ca4cc6c5b493]]
29 -|(% style="width:121px" %) |(% style="width:1360px" %)
30 -
31 -