Когда несколько MessageConsumer подключаются к одной и той же очереди (Websphere MQ), как сбалансировать нагрузку на потребителя сообщений?

Я использую WebSphere MQ 7, и у меня есть два клиента, подключенные к одному и тому же QMgr и использующие сообщения из одной очереди, например следующий код:

 while (true) {
        TextMessage message = (TextMessage) consumer.receive(1000);
        if (message != null) {
            System.out.println("*********************" + message.getText());
        }
    }

Я обнаружил, что только один клиент всегда получает сообщения. Есть ли способ разрешить балансировку нагрузки на потребление сообщений в двух клиентах? Любые параметры конфигурации на стороне сервера MQ?


load-balancing websphere ibm-mq jms
person L.J.W    schedule 10.12.2012    source источник

Ответы (2)


arrow_upward
3
arrow_downward

При управлении дескрипторами очереди WMQ НАМНОГО быстрее помещает их в стек, а не в очередь LIFO. Таким образом, если сообщения поступают в очередь медленнее, чем требуется для их обработки, возможно, экземпляр обработает сообщение и выполнит еще один GET, который WMQ помещает в стек. В результате только один экземпляр будет видеть сообщения в сценарии использования с небольшим объемом.

В более крупных средах, где есть много экземпляров, ожидающих сообщений, возможно, что активность будет циклически перемещаться среди части этих экземпляров, в то время как другие экземпляры будут ждать сообщений. Например, если в очереди 10 сообщений GETter, вы можете увидеть три обрабатываемых сообщения и 7 незанятых.

Хотя это значительно быстрее для MQ, это сбивает с толку клиентов, которые не знают, как это работает внутри, и поэтому они открывают PMR, задавая именно этот вопрос. IBM пришлось выбирать из нескольких альтернатив:

  • Добавлено несколько путей кода для управления стеком для повышения производительности при полной загрузке по сравнению с управлением по LIFO для очевидной балансировки при небольшой загрузке. Это раздувает код, добавляет много новых точек принятия решений, которые приводят к ошибкам, и решает проблему восприятия, а не надежности или производительности.
  • Объясните клиентам, как это работает. Конечно, как только вы это задокументируете, вы не сможете это изменить. Я узнал об этом, посетив презентацию "WMQ Internals" на IMPACT. Его нет в информационном центре, поэтому IBM может изменить его, но он доступен для клиентов.
  • Ничего не делать. Хотя это наилучший результат с точки зрения разработки кода, такое поведение противоречит здравому смыслу. Пользователям необходимо понять, почему что-то работает не так, как ожидалось, и они будут тратить время, пытаясь найти конфигурацию, обеспечивающую желаемое поведение, или открыть PMR.

Я не знаю точно, работает ли это до сих пор, но я ожидаю, что это так. Раньше я тестировал это, помещая много сообщений в очередь сразу, а затем наблюдая, как они распределяются. Если вы поместите около 50 сообщений в очередь за одну единицу работы, вы должны увидеть лучшее распределение между двумя экземплярами.

Как вы сразу бросаете 50 сообщений в очередь? Сначала сгенерируйте их с выключенными приложениями или в запасную очередь. Если вы создали их в целевой очереди, используйте программу Q, чтобы переместить их в запасную очередь. Теперь запустите приложения и убедитесь, что количество IPPROC в очереди равно количеству экземпляров приложения, которое вы запустили. Снова используя Q, скопируйте все сообщения в исходную очередь за одну единицу работы. Поскольку все они становятся доступными в очереди одновременно, вашим двум экземплярам приложения должно быть немедленно передано сообщение. Если вы использовали копирование вместо перемещения, вы можете повторять это столько раз, сколько потребуется.

person T.Rob    schedule 10.12.2012

arrow_upward
0
arrow_downward

Ваш клиент мало что делает, поэтому один экземпляр, вероятно, может справиться с полной нагрузкой. Попробуйте реализовать более реалистичную рабочую нагрузку или, что еще проще, поместите Thread.sleep в клиент.

person Nicholas    schedule 10.12.2012