Отказоустойчивый асинхронный издатель JMS - PullRequest
Новая
       2

Отказоустойчивый асинхронный издатель JMS

4 голосов
/ 02 марта 2011

В нашей архитектуре JMS издатель может продолжать работать (и генерировать новые сообщения), даже если соединение с локальной сетью потеряно. Можно ли сделать сервер издателя терпимым к сбоям сети или брокера с помощью JMS:

  1. публикация вызова может не блокировать приложение, даже если брокер недоступен;
  2. опубликованные сообщения (во время простоя) должны быть доставлены после восстановления сетевого подключения;

Насколько я понимаю, это можно сделать с помощью встроенного (локального) посредника на каждом издательском компьютере. Если это единственный способ, есть ли какие-либо неочевидные проблемы с этой топологией - производительность, обслуживание и т. Д.? Будет ли местный брокер терпимым к отключениям?

Ответы [ 3 ]

2 голосов
/ 02 марта 2011

Я не пробовал это, но кажется, что вы можете использовать локальное переключение при сбое, чтобы уменьшить сопротивление: С ActiveMQ вы можете настроить отказоустойчивый транспорт: 

failover:(tcp://primary:61616,tcp://secondary:61616)?randomize=false

Чтобы попытаться нарисовать это: 

client +---> primary: network broker <-------+
       |                                     |
       +---> secondary: embedded broker -----+

Здесь первичным будет ваш сетевой брокер, а вторичным - локально встроенный брокер с мостом к первичному брокеру. Кажется, что это будет хорошо работать, когда клиент публикует allot; Я не уверен, будет ли это лучше для подписчиков, чем решение, предложенное @Biju: показано ниже: 

client +---> secondary: embedded broker ------> primary: network broker

Например, вот мой встроенный брокер (который обычно непостоянен). 

<bean id="activeMQBroker" class="org.apache.activemq.broker.BrokerService">
    <property name="transportConnectors">
        <list>
                <bean id="brokerConnection" class="org.apache.activemq.broker.TransportConnector">
                    <property name="connectUri">
                        <bean id="brokerURI" class="java.net.URI">
                            <constructor-arg value="tcp://localhost:61616" />
                        </bean>
                    </property>
                </bean>
        </list>
    </property>

    <property name="persistent" value="true" />
</bean>
0 голосов
/ 02 марта 2011

Распределенная архитектура, если администраторы очередей \ брокеры очень распространены в описанных вами случаях.

Точная конфигурация зависит от конкретного продукта, который вы используете, но обычно хорошо документирована и проста в управлении

Что касается локальной избыточности, вы можете использовать два таких администратора очередей в отказоустойчивой конфигурации (опять же, точный метод создания отказоустойчивых кластеров зависит от продукта), но, похоже, это излишнее.

JMS стандартизирует только API поставщика очереди сообщений, другие

0 голосов
/ 02 марта 2011

Единственный способ, которым я могу придумать, - это то, что вы предложили -

  1. Иметь локального встроенного брокера и обеспечить мост от этого встроенного брокера к сетевому брокеру. Даже локальный может быть отключен, поэтому вам, возможно, придется публиковать транзакции между вашими ресурсами (инфраструктура db и jms)
  2. Не публикуйте напрямую, вместо этого используйте абстракцию, которая буферизует ее - в базу данных, файл и т. П. Выше, в локальный встроенный jms, и предоставьте мост, подобный указанному выше, из буфера в очередь JMS.
...