Исходный код вики Механизмы
Редактировал(а) Alexandr Fokin 2023/12/16 14:13
Последние авторы
| author | version | line-number | content |
|---|---|---|---|
| 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" %)Acknowledgements|(% style="width:1360px" %) | ||
| 30 | |||
| 31 |