ActiveMq Artemis - конфигурация отказоустойчивого кластера

Поизучал гарантии различных конфигураций кластеров Артемис против следующих бизнес требований:

1) Должны обеспечивать порядок сообщений ( потребитель должен вычитывать сообщения в правильном порядке - дальше его проблемы); 2) Сообщения не должны теряться; 3) При отказе одной ноды кластер должен продолжить работу; 4) Обработка сплит-брейна;

Варианты кластеров:

(1) MASTER + 2 SLAVE - синхронная репликация, каждый узел хранит копию журнала. (2) 3 пары MASTER/SLAVE - репликация только между парой, каждые пары хранят независимые журналы:

Выдержка из доки: Failover support in ActiveMQ Artemis is provided by a master/slave pair as that is the only configuration where two brokers have the same journal data (either via shared-storage or replication). Failover between one master and another master is not supported.

Этот кластер советует оф документация как способ решения проблемы сплитбрейна

(3) 1 пара MASTER/SLAVE с общим хранилищем ( в этом случае второй SLAVE не нужен см. далее)

Для первого кластера не обеспечивается обработка сплитбрейна:

The first thing to note is that using a single live/backup pair (or even live/backup/backup triplet) with network replication is dangerous due to the risk of "split-brain."

Для второго мы можем потерять порядок сообщений:

В варианте, если одновременно откажут 2 узла в 1 паре MASTER/SLAVE получится следующая ситуация (смотри выдержку из доки выше ): 1) Отправитель записал сообщение, оно забалансировалось на 1 из 3 пар. 2) Пара упала (MASTER + SLAVE) 3) Отправитель записал еще сообщение - оно попало на живую пару 4) Получатель вычитал его 5) Первое сообщение лежит в журналах первой пары и ждет когда по крайней мере MASTER или SLAVE поднимутся 6) Порядок нарушен

В третьем варианте общее хранилище будет узким местом и если откажет оно, то брокер не сможет принимать/отдавать сообщения

Можно ли настроить кластер по вышеописанным требованиям?


Ответы (0 шт):