Изменения документа RabbitMQ
Редактировал(а) Alexandr Fokin 2024/06/09 19:02
<
>
отредактировано Alexandr Fokin
на 2021/01/06 13:55
на 2021/01/06 13:55
отредактировано Alexandr Fokin
на 2021/01/05 16:26
на 2021/01/05 16:26
Изменить комментарий:
К данной версии нет комментариев
Комментарий
-
Объекты (0 изменено, 0 добавлено, 1 удалено)
Подробности
- XWiki.XWikiComments[3]
-
- Автор
-
... ... @@ -1,1 +1,0 @@ 1 -XWiki.cccc1808 - Комментарий
-
... ... @@ -1,16 +1,0 @@ 1 -В RabbitMq есть возможности для создания кластеров, состоящих из нескольких узлов. 2 -По умолчанию очереди не реплицируются между нодами кластера и в случае выхода из строя ноды с очередью, очередь будет потеряна. 3 - 4 -Также существует механизм зеркалирования, который позволяет производить репликацию. В таком случае для очереди одна нода выступает в роли мастера, остальные в роли подчиненного. 5 -Чтение и запись будут проходить через мастер ноду, а от нее распространяться на подчиненные ноды. В случае выхода из строя мастер ноды, одна из подчиненных нод берет на себя роль мастер ноды. Если упавшая нода оживает, то она возвращается в кластер, но в роли подчиненной ноды. 6 -Зеркалирование можно происходит, как на все ноды в кластере, таки и на несколько (задается количеством реплик или указанием конкретных улов кластера). 7 -При зеркалировании отправка сообщения с клиента считается успешно завершенной только после того, как мастер нода очереди распространило реплики сррбщения на все подчиненные ноды репликации. При обращении к подчиненной ноде для выполнения отправки или потребления сообщения, подчиненная нода выполняет обращение к мастер ноде для очереди. (Поэтому, по возможности, имеет смысл подключаться к нодей, выступающей в роде мастер-ноды для конкретной очереди) 8 - 9 -Вопросы: 10 -1) Как поведет себя кластер в случае распада на несколько сегментов из-за проблем с сетью? А именно: если сегменты продолжат получать сообщения, то что будет происходит при соединении сегментов. Как будет синхронизироваться состояние очередей. Скорее всего в данном случае мы не сможем гарантировать то, что разделенные сегменты могут отдать одно и то же сообщение потребителям в итоге получив дублирование. 11 - 12 -Примечание: 13 -Существуют и альтернативные методики синхронизации основанные на 14 -1) Плагине федераций 15 -2) Плагине Лапата. (клиент-потребитель, запущенный на стороне брокера и автоматически пересылающий сообщения из одной очереди в другие) 16 -3) Явное управление со стороны клиентов очереди, отправка сообщения сразу на несколько брокеров. - Дата
-
... ... @@ -1,1 +1,0 @@ 1 -2021-01-06 13:44:43.300