Compartilhar via

Práticas recomendadas para comunicação em fila

Este tópico fornece práticas recomendadas para comunicação na fila no WCF (Windows Communication Foundation). As seções a seguir discutem as práticas recomendadas de uma perspectiva de cenário.

Mensagens rápidas e de melhor esforço na fila

Para cenários que exigem separação que as mensagens na fila fornecem e mensagens rápidas e de alto desempenho com garantias de melhor esforço, use uma fila não transacional e defina a propriedade ExactlyOnce como false.

Além disso, você pode optar por não incorrer no custo de gravações de disco definindo a Durable propriedade como false.

A segurança tem implicações no desempenho. Para obter mais informações, consulte Considerações de desempenho.

Mensagens na fila de ponta a ponta confiáveis

As seções a seguir descrevem as práticas recomendadas para cenários que exigem mensagens confiáveis de ponta a ponta.

Transferência Confiável Básica

Para confiabilidade de ponta a ponta, defina a propriedade ExactlyOnce como true a fim de garantir a transferência. A Durable propriedade pode ser definida como true ou false dependendo de seus requisitos (o padrão é true). Em geral, a propriedade Durable é definida como true como parte da confiabilidade de ponta a ponta. O comprometimento é um custo de desempenho, mas torna a mensagem durável para que a mensagem não seja perdida se um gerenciador de filas falhar.

Uso de transações

Você deve usar transações para garantir a confiabilidade de ponta a ponta. ExactlyOnce garantem apenas que as mensagens sejam entregues na fila de destino. Para garantir que a mensagem seja recebida, use transações. Sem transações, se o serviço falhar, você perderá a mensagem que está sendo entregue, mas, na verdade, será entregue ao aplicativo.

Use filas de mensagens de mortas

As filas de mensagens mortas garantem que você seja notificado se uma mensagem não for entregue à fila de destino. Você pode usar a fila de mensagens mortas fornecida pelo sistema ou uma fila de mensagens mortas personalizada. Em geral, usar uma fila de mensagens mortas personalizada é melhor porque permite que você envie mensagens de mensagens mortas de um aplicativo para uma única fila de mensagens mortas. Caso contrário, todas as mensagens de mensagens mortas que ocorrem para todos os aplicativos em execução no sistema são entregues em uma única fila. Cada aplicativo deve pesquisar na fila de mensagens mortas para encontrar as mensagens de mensagens mortas relevantes para esse aplicativo. Às vezes, o uso de uma fila de mensagens mortas personalizada não é viável, como ao usar o MSMQ 3.0.

Não é recomendável desativar filas de mensagens mortas para comunicação confiável de ponta a ponta.

Para obter mais informações, consulte Como usar filas de Dead-Letter para lidar com falhas de transferência de mensagens.

Uso de tratamento de mensagens suspeitas

O tratamento de mensagens suspeitas oferece a capacidade de recuperação da falha ao processar mensagens.

Ao usar o recurso de tratamento de mensagens suspeitas, verifique se a ReceiveErrorHandling propriedade está definida como o valor apropriado. Definir Drop significa que os dados serão perdidos. Por outro lado, defini-la como Fault causa uma falha no host de serviço quando ele detecta uma mensagem suspeita. Usar o MSMQ 3.0 Fault é a melhor opção para evitar a perda de dados e mover a mensagem de veneno para fora do caminho. Usar o MSMQ 4.0 Move é a abordagem recomendada. Move move uma mensagem envenenada para fora da fila para que o serviço possa continuar a processar novas mensagens. O serviço de mensagem de veneno pode processar a mensagem venenosa separadamente.

Para obter mais informações, consulte Tratamento de Mensagens Maliciosas.

Atingindo alta capacidade de processamento

Para obter alta taxa de transferência em um único ponto de extremidade, use o seguinte:

  • Envio em lote transacionado. O envio em lote transacionado garante que muitas mensagens possam ser lidas em uma única transação. Isso otimiza as confirmações de transação, aumentando o desempenho geral. O custo do envio em lote é que, se ocorrer uma falha em uma única mensagem em um lote, todo o lote será revertido e as mensagens deverão ser processadas uma de cada vez até que seja seguro enviar em lote novamente. Na maioria dos casos, mensagens suspeitas são raras, portanto, o envio em lote é a maneira preferencial de aumentar o desempenho do sistema, especialmente quando você tem outros gerenciadores de recursos que participam da transação. Para obter mais informações, confira Como enviar mensagens em lote em uma transação.

  • Concorrência. A simultaneidade aumenta a taxa de transferência, mas a simultaneidade também afeta a contenção de recursos compartilhados. Para obter mais informações, consulte Concorrência.

  • Limitação. Para obter um desempenho ideal, limite o número de mensagens no pipeline do dispatcher. Para obter um exemplo de como fazer isso, consulte Limitação.

Ao usar o envio em lote, lembre-se de que a simultaneidade e a limitação se traduzem em lotes simultâneos.

Para obter maior taxa de transferência e disponibilidade, use um farm de serviços WCF que leiam da fila. É necessário que todos esses serviços exponham o mesmo contrato no mesmo endpoint. A abordagem de farm funciona melhor para aplicativos que têm altas taxas de produção de mensagens porque permite que vários serviços sejam lidos da mesma fila.

Ao usar farms, lembre-se de que o MSMQ 3.0 não dá suporte a leituras transacionadas remotas. O MSMQ 4.0 dá suporte a leituras transacionadas remotas.

Para obter mais informações, confira Como enviar mensagens em lote em uma transação.

Enfileiramento com unidade de semântica de trabalho

Em alguns cenários, um grupo de mensagens em uma fila pode estar relacionado e, portanto, a ordenação dessas mensagens é significativa. Nesses cenários, processe um grupo de mensagens relacionadas como uma única unidade: todas ou nenhuma mensagem é processada com êxito. Para implementar esse comportamento, use sessões com filas.

Para obter mais informações, consulte Agrupamento de mensagens enfileiradas em uma sessão.

Correlacionar mensagens de solicitação-resposta

Embora as filas normalmente sejam unidirecionais, em alguns cenários, talvez você queira correlacionar uma resposta recebida a uma solicitação enviada anteriormente. Se você precisar dessa correlação, é recomendável aplicar seu próprio cabeçalho de mensagem SOAP que contenha informações de correlação com a mensagem. Normalmente, o remetente anexa esse cabeçalho com a mensagem e o receptor, ao processar a mensagem e responder novamente com uma nova mensagem em uma fila de resposta, anexa o cabeçalho da mensagem do remetente que contém as informações de correlação para que o remetente possa identificar a mensagem de resposta com a mensagem de solicitação.

Integração com aplicativos não WCF

Use MsmqIntegrationBinding ao integrar serviços ou clientes do WCF com clientes ou serviços não WCF. O aplicativo não WCF pode ser um aplicativo MSMQ escrito usando System.Messaging, COM+, Visual Basic ou C++.

Ao usar MsmqIntegrationBinding, lembre-se do seguinte:

  • Um corpo de mensagem WCF não é o mesmo que um corpo de mensagem MSMQ. Ao enviar uma mensagem WCF usando uma vinculação em fila, o corpo da mensagem WCF é colocado dentro de uma mensagem MSMQ. A infraestrutura do MSMQ está alheia a essas informações extras; ele vê apenas a mensagem MSMQ.

  • MsmqIntegrationBinding dá suporte a tipos de serialização populares. Com base no tipo de serialização, o tipo de corpo da mensagem MsmqMessage<T>genérica usa parâmetros de tipo diferentes. Por exemplo, ByteArray requer MsmqMessage\<byte[]> e Stream requer MsmqMessage<Stream>.

  • Com a serialização XML, você pode especificar o tipo conhecido usando o KnownTypes atributo no <elemento de comportamento> que é usado para determinar como desserializar a mensagem XML.

Consulte também

  • Last updated on