ActiveMQ Артемида. Надежный кластер с синхронной репликацией

Question

Я хочу настроить кластер со следующим ожидаемым поведением:

1. Кластер должен быть HA (минимум 3 узла).
2. У меня есть очереди, в которых важно поддерживать обработку заказа. Потребитель всегда читает эту очередь в одном потоке. Если он принял сообщение, то мы считаем нашу задачу выполненной.
3. Мне не нужна балансировка нагрузки - мне важно поддерживать порядок сообщений.
4. Я хочу избежать разделения -brain.
5. Если у нас есть 3 узла, то если один из узлов выходит из строя, кластер должен продолжать работать.

Я попробовал следующие конфигурации:

1. ведущий + ведомый + ведомый с репликацией.

Работает. Но не решает проблему расщепления мозга

master + slave + slave + Pinger

Насколько я понимаю, это не дает 100% гарантии обнаружения проблем в сети. Мы также можем получить сплит-мозг.

3 пары активных / резервных узлов.

Это решенная проблема с разделенным мозгом, но как мы можем избежать следующей ситуации:

1. Производитель отправляет сообщение группе А в очереди (где важно поддерживать порядок обработки)
2. Сбой группы A (1/3 всех узлов 2/6)
3. Сообщение, хранящееся в журнале группы A
4. Кластер продолжает работать;
5. Производитель отправляет сообщение группе B в очереди (где важно поддерживать порядок обработки)
6. Потребитель получил это сообщение первым; Мы не поддержали требуемый порядок сообщений.

Как создать кластер для решения этих проблем?

Answer 1

Вы не можете добиться желаемого поведения с помощью репликации. Вам необходимо использовать разделяемое хранилище между узлами. Если вы должны использовать 3 узла, я бы порекомендовал master + slave + slave. В противном случае я бы порекомендовал master + slave.

Кроме того, для чего это стоит, репликация не является синхронной. Это асинхронный и неблокирующий. Тем не менее, это все еще надежно. Например, если посредник настроен для HA с репликацией и получает устойчивое сообщение от клиента, он сохранит это сообщение на диск и отправит его в реплицированную резервную копию одновременно без блокировки. Однако он будет ждать обеих операций до конца sh, прежде чем ответить клиенту, что он получил сообщение. Это обеспечивает гораздо большую пропускную способность сообщений, чем при синхронной архитектуре.

Кроме того, стоит отметить, что ведется работа по изменению работы репликации, чтобы сделать ее более устойчивой к разделенному мозгу и включить одну пару «главный + подчиненный», которая подходит для производственного использования.