Многопоточный .NET RabbitMQ издатель - PullRequest
3 голосов
/ 21 февраля 2012

У нас есть следующий сценарий, использующий библиотеку .NET RabbitMQ:

Рабочий поток выбирает сообщения 'request' из очереди и отправляет их в несколько рабочих потоков для обработки.После завершения каждый рабочий поток затем отправляет другое сообщение.

Мой вопрос: какой «шаблон» рекомендуют отправителю для получения максимальной пропускной способности и стабильности ?.Например:

1) Единственный экземпляр «издателя», к которому получают доступ все рабочие потоки с помощью одного соединения и IModel (используя «замок» для синхронизации доступа к IModel)

2) Единственный экземпляр 'publisher', к которому обращаются все рабочие потоки с одним подключением и который создает новую IModel для каждого запроса на отправку.

или что-то еще?

1 Ответ

4 голосов
/ 28 февраля 2012

Согласно руководству пользователя RabbitMQ «Экземпляры IModel не должны использоваться более чем одним потоком одновременно: код приложения должен поддерживать четкое представление о владении потоком для экземпляров IModel». Если IModel используется совместно, следует использовать блокировку, как вы сказалино, по моему мнению, это приводит к более сложному коду, потому что соединение и модель должны поддерживаться в случае разъединения.

Хотя вы не упоминаете, требуются ли транзакции для обеспечения большей надежности при доставке сообщений,Канал должен быть установлен в режиме транзакции, и, возможно, вам потребуется транзакция для каждой доставки.

Использование новой модели для доставки обеспечивает более простое управление ошибками, но, очевидно, замедлит пропускную способность (и то же самое, используя транзакции).).

Вы также можете, в зависимости от ваших требований, использовать недлительные очереди и прямые или разветвленные обмены, которые обеспечивают лучшую пропускную способность.

Например, на компьютере разработчика служба Windows tОн принимает сообщения из очереди, используя один единственный поток (десериализацию, создает некоторую бизнес-логику, и, наконец, отправляет новое сериализованное сообщение, используя транзакции, открывая / закрывая соединение, и модель может обрабатывать около 3000 сообщений в секунду.(сериализация была выполнена через XmlSerializer, который хуже, чем DataContractSerializer)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...