Рекомендации по обмену данными в очереди

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

Быстрый обмен сообщениями в очереди Best-Effort

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

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

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

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

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

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

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

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

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

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

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

Отключение очередей недоставленных писем для сквозного надежного взаимодействия не рекомендуется.

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

Использование процесса обработки Poison-Message

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

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

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

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

Чтобы достичь высокой пропускной способности в одной конечной точке, используйте следующую команду:

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

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

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

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

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

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

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

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

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

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

Сопоставление сообщений Request-Reply

Хотя очереди обычно односторонние, в некоторых сценариях может потребоваться сопоставить полученный ответ с запросом, отправленным ранее. Если требуется такая корреляция, рекомендуется применить собственный заголовок сообщения 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-сообщения.

См. также

  • Last updated on