#redhat #activemq-artemis #amq
#redhat #activemq-artemis #amq
Вопрос:
Я пытаюсь реализовать порядок сообщений в кластере Apache Artemis. Производители / потребители, подключающиеся к кластеру, обеспечивают высокую доступность. Таким образом, в один момент времени будет два экземпляра одного и того же приложения, подключающегося к теме или очереди. До сих пор я мог найти следующие два метода, которые можно использовать для упорядочения в кластере Red Hat AMQ / Artemis:
- Группы сообщений (надежны только при наличии одного потребителя на узел в кластере в соответствии с документацией)
- Эксклюзивные очереди (порядок сообщений сохраняется только на одном узле).
Я полностью понимаю, что использование кластера и ожидание упорядочения сообщений являются противоречивыми требованиями, но это все еще требование, которое должно быть реализовано в проекте, над которым я работаю, поскольку потребители не могут справиться со сложностью обработки сообщений не по порядку.
Какие альтернативы вышеуказанному можно использовать для реализации порядка сообщений в кластере Artemis ActiveMQ / Red Hat AMQ?
Комментарии:
1. Можете ли вы пояснить, почему кластеризация и упорядоченный обмен сообщениями являются обязательным требованием?
2. Мы используем кластер корпоративного уровня, который используется командами polygot. Несмотря на то, что мы можем использовать только 1 пару master / slave в кластере, она по-прежнему недоступна, поскольку она не появляется в центрах обработки данных. Короче говоря, мы не контролируем топологию. Некоторые приложения могут обрабатывать неупорядоченные сообщения на стороне потребителя, в то время как другие не могут. Кроме того, потребительские приложения имеют развертывание с высокой доступностью с активной / активной конфигурацией, поэтому множество потребителей начинают потреблять, нарушая порядок сообщений в источнике.
Ответ №1:
В кластеризованной среде эксклюзивный потребитель привязан к каждой очереди каждого брокера, поэтому в зависимости от конфигурации балансировки нагрузки сообщений у вас может быть один потребитель для каждого брокера, получающего сообщения. Это нарушает порядок. Ваш производитель и потребители должны находиться в одном экземпляре брокера, чтобы сохранить порядок.
Как вы говорите, функциональность кластерных групп сообщений ненадежна, тем не менее, она может быть полезна в некоторых, очень специфических случаях использования. Также обратите внимание, что для HA недостаточно иметь кластер брокеров. Вам необходимо явно настроить HA (совместное хранилище или репликацию), в противном случае, если брокер выйдет из строя навсегда, все его сообщения будут потеряны.
Комментарии:
1. Я попробовал этот пример в соответствии с документацией, если у нас настроена эксклюзивная очередь в кластере из 2 узлов. Один потребитель C1 подключается к этой эксклюзивной очереди на узле 1, а другой потребитель C2 подключается к той же эксклюзивной очереди на узле 2. Предположим, что производитель отправляет 2 сообщения. Первое сообщение достигает C1 (и подтверждение этого получателя занимает много времени). Тем временем потребитель C2 получает второе сообщение, поэтому конечный результат — порядок сообщений не гарантируется. Как мы можем решить эту проблему?
2. Как я уже сказал, не используйте кластеризованные группы и настройте своих клиентов так, чтобы они всегда подключались к одному и тому же кластерному брокеру. Таким образом, вы можете использовать локальные группы, которые работают надежно и с большей производительностью.
3. Этот пример, о котором я упоминал выше, касается эксклюзивных очередей, а не кластеризованных групп, поправьте меня, если я ошибаюсь?
4. Обновил мой ответ, добавив ваш тестовый вариант использования.