Клиентский сервер с использованием WebSphere MQ

Вариант использования, который вы описываете, невероятно узок. Это не просто случай «сокетов или очередей», но другие факторы должны учитывать бизнес-ситуацию:

1. Как вещь будет контролироваться и управляться? Нужно ли будет записывать все части, которые сообщают о работоспособности системы в NOC и предоставлять статистику сообщений, или я могу использовать то, что предоставляет MQ?
2. Нужно ли ставить в очередь или это действительно синхронное приложение?
3. Это действительно точка-точка или участвующие приложения участвуют в экосистеме сервисов и восходящих / нисходящих соединений? С чем еще нужно интегрироваться?
4. Есть ли необходимость в обогащении сообщений, маршрутизации, разветвлении, разветвлении, публикации / подписке или других функциях? Написать код или использовать нативные функции WMQ / WMQ Broker?
5. Требуется ли аутентификация для соединений? Шифрование? Написать код или использовать встроенные функции WMQ?
6. Существуют ли факторы соответствия нормативным требованиям и, если да, какова стоимость аудита пользовательского кода по сравнению с транспортировкой COTS?
7. Есть ли у магазина глубокие навыки C ++ и готов ли он поддерживать эту глубину стенда на протяжении всего жизненного цикла кода?
8. Как управляется конфигурация соединения и поддерживает ли она HA и DR без проблем? Написать код или использовать встроенные функции WMQ?
9. Как будет управляться логика исключений и автоматическое переподключение? Написать код или использовать встроенные функции WMQ?

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

Что касается конкретных вопросов …

Доступ к очередям управляется так, как вы надеетесь. Несколько потоков конкурируют за одни и те же сообщения, но сообщение, доставленное одному, не доставляется другому потоку. Исключения составляют случаи, когда сообщение откатывается и снова становится доступным, или приложение использует pub / sub и намеренно получает более одной копии сообщения.

На стороне приложения вызовы являются потокобезопасными в течение сеанса. Так что все потоки используют один и тот же сеанс COMMIT все вместе. Обычно пара потоков, использующих запрос / ответ, работает совместно. В противном случае один сеанс на поток дает вам то, что вам нужно.

Что касается производительности, это сравнение яблок с апельсинами. Вопрос состоит в том, выполняет ли программа сокетов C ++, которая предоставляет все службы, диагностику, отказоустойчивость и другие функции асинхронного транспорта обмена сообщениями, наравне с этим транспортом. Ответа обычно нет. WMQ был оптимизирован в течение 20 лет, чтобы делать что-то одно и делать это очень хорошо. Новая пользовательская программа сокетов C ++ будет перемещать данные быстрее, но не будет обеспечивать ту же функциональность. Таким образом, все сводится к тому, нужно ли приложению настолько мало функциональности WMQ, что в конечном итоге дешевле будет настраивать код для нескольких необходимых функций, а затем поддерживать их на протяжении всего срока службы приложения. Опять же, ответ обычно нет.

Подробнее о пропускной способности сообщений см. SupportPacs найдите и найдите те, чьи имена начинаются с MP__, для нужной платформы и версии. Достижение 10k MPS для небольших сообщений возможно даже на скромном оборудовании.