Рекомендации по взаимодействию с использованием очередей

  • Статья

В этом разделе приведены рекомендации по обмену данными в очереди в Windows Communication Foundation (WCF). В последующих разделах рассматриваются рекомендации с точки зрения сценариев.

Быстрый наилучший обмен сообщениями с использованием очередей

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

Дополнительно можно исключить затраты на запись на диск, задав для свойства Durable значение false.

Безопасность влияет на производительность. Дополнительные сведения см. в разделе "Рекомендации по производительности".

Надежный сквозной обмен сообщениями с использованием очередей

В последующих разделах приводятся рекомендации для сценариев, требующих надежного сквозного обмена сообщениями.

Базовая надежная передача

Для сквозной надежности установите для свойства ExactlyOnce значение true, чтобы обеспечить передачу. Для свойства Durable можно задать значение true или false, в зависимости от требований (значение по умолчанию - true). Как правило, для свойства Durable задается значение true как составная часть сквозной надежности. Компромисс достигается за счет производительности, но сообщения становятся устойчивыми и не теряются в случае сбоя диспетчера очередей.

Использование транзакций

Необходимо использовать транзакции для обеспечения сквозной надежности. Гарантии ExactlyOnce обеспечивают только доставку сообщений в целевую очередь. Чтобы гарантировать получение сообщений, используйте транзакции. Без транзакций в случае сбоя службы будет потеряно сообщение, находящееся в процессе доставки, но фактически доставленное в приложение.

Использование очередей недоставленных сообщений

Очереди недоставленных сообщений обеспечивают уведомления в случаях, когда не удалось доставить сообщение в целевую очередь. Можно использовать системную очередь недоставленных сообщений или пользовательскую очередь недоставленных сообщений. Как правило, лучше использовать пользовательскую очередь недоставленных сообщений, так как она позволяет отправлять недоставленные сообщения из одного приложения в отдельную очередь недоставленных сообщений. В противном случае все недоставленные сообщения из всех работающих в системе приложений будут доставляться в одну очередь. Затем каждое приложение должно просматривать очередь недоставленных сообщений, чтобы найти недоставленные сообщения, относящиеся к этому приложению. Иногда использование пользовательской очереди недоставленных сообщений невозможно, например, при использовании MSMQ 3.0.

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

Дополнительные сведения см. в разделе "Использование очередей недоставленных писем" для обработки сбоев передачи сообщений.

Использование обработки подозрительных сообщений

Обработка подозрительных сообщений обеспечивает возможность восстановления после сбоя при обработке сообщений.

При использовании возможности обработки подозрительных сообщений убедитесь, что для свойства ReceiveErrorHandling задано подходящее значение. Если свойству присвоено значение Drop, это означает потерю данных. С другой стороны, значение Fault этого свойства вызывает сбой узла службы в случае обнаружения подозрительного сообщения. При использовании MSMQ 3.0 значение Fault - это наилучший способ избежать потери данных и избавиться от подозрительного сообщения. При использовании MSMQ 4.0 Move является рекомендуемым способом. Операция Move обеспечивает перемещение подозрительного сообщения из очереди, чтобы служба могла продолжать обрабатывать новые сообщения. Затем служба подозрительных сообщений может отдельно обработать подозрительное сообщение.

Дополнительные сведения см. в разделе "Обработка подозрительных сообщений".

Достижение высокой пропускной способности

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

  • Пакетирование с поддержкой транзакций. Пакетирование с поддержкой транзакций обеспечивает возможность чтения нескольких сообщений в одной транзакции. При этом оптимизируются фиксации транзакции, что повышает общую производительность. Недостаток пакетирования заключается в том, что при сбое в одном сообщении из пакета производится откат всего пакета, и сообщения требуется обрабатывать по одному до тех пор, пока не появится возможность снова объединять их в пакет. В большинстве случаев подозрительные сообщения встречаются редко, поэтому пакетирование - это предпочтительный способ повышения производительности системы, особенно при наличии других диспетчеров ресурсов, участвующих в транзакции. Дополнительные сведения см. в разделе "Пакетные сообщения" в транзакции.

  • Параллелизм. Параллелизм увеличивает пропускную способность, однако при этом влияет на состязание за общие ресурсы. Дополнительные сведения см. в разделе "Параллелизм".

  • Регулирование. Для получения оптимальной производительности следует регулировать количество сообщений в конвейере диспетчера. Пример этого см. в разделе "Регулирование".

При использовании пакетирования помните, что параллелизм и регулирование означает параллельные пакеты.

Чтобы достичь более высокой пропускной способности и доступности, используйте ферму служб WCF, которые считываются из очереди. Для этого необходимо, чтобы все эти службы предоставляли один и тот же контракт в одной конечной точке. Использование ферм больше всего подходит для приложений, создающих много сообщений, так как это позволяет нескольким службам производить чтение из одной очереди.

При использовании ферм помните, что в MSMQ 3.0 удаленные чтения в транзакциях не поддерживаются. В MSMQ 4.0 удаленные чтения в транзакциях поддерживаются.

Дополнительные сведения см. в разделе "Пакетные сообщения" в транзакции.

Организация очереди с семантикой единицы работы

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

Дополнительные сведения см. в разделе "Группирование сообщений в очереди" в сеансе.

Коррелирование сообщений типа «запрос-ответ»

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

Интеграция с приложениями, не являющимися приложениями WCF

Используйте MsmqIntegrationBinding при интеграции служб WCF или клиентов с службами или клиентами, отличными от WCF. Приложение, отличное от WCF, может быть приложением MSMQ, написанным с помощью System.Messaging, COM+, Visual Basic или C++.

При использовании MsmqIntegrationBinding помните следующее:

  • Текст сообщения WCF не совпадает с текстом сообщения MSMQ. При отправке сообщения WCF с помощью привязки в очереди текст сообщения WCF помещается в сообщение MSMQ. Инфраструктура MSMQ не замечает эту дополнительную информацию - она видит только сообщение MSMQ.

  • Класс MsmqIntegrationBinding поддерживает распространенные типы сериализации. На основе типа сериализации тип тела универсального сообщения, MsmqMessage<T>, принимает параметры разных типов. Например, для ByteArray требуется MsmqMessage\<byte[]>, а для Stream требуется MsmqMessage<Stream>.

  • При сериализации XML можно указать известный тип с помощью KnownTypes атрибута в <элементе поведения> , который затем используется для определения десериализации XML-сообщения.

См. также