Boa estratégia de enfileiramento de mensagens?

votos
9

Atualmente estou criando um aplicativo que eu acabará por querer mudar para o Windows Azure. No curto prazo, no entanto, ele será executado em um servidor que vou me hospedar.

A aplicação envolve uma série de aplicações web separados - alguns deles são essencialmente serviços WCF que recebem dados, e alguns são locais para usuários gerenciar dados. Além disso, haverá a necessidade de ser um serviço de trabalho em execução em segundo plano que irá processar os dados de várias maneiras.

Estou muito interessado em usar uma arquitetura dissociada para isso. Idealmente, eu estou querendo os componentes (ou seja, aplicativos web e de serviços trabalhador) para saber o mínimo possível sobre o outro. Parece que usando uma fila de mensagens será a melhor solução aqui - as aplicações web pode enfileirar mensagens com unidades de trabalho para a fila eo serviço trabalhador pode escolhê-los e processá-los, conforme necessário.

No entanto, eu quero trabalhar para fora um bom conjunto de tecnologias para fazer isso, tendo em conta que eu vai finalmente estar se movendo para Azure e quer minimizar a quantidade de re-trabalho que você precisa fazer quando eu migrar para a nuvem . Azure tem um componente Queue construído em que parece ideal para as minhas necessidades. O que eu gostaria de fazer é criar algo me que irá imitar este, tanto quanto possível.

Parece que existem várias opções (estou usando .NET em Windows, com um back-end SQL Server 2005) - aqueles que eu encontrei até agora são:

  • MSMQ
  • corretor de serviço do SQL Server
  • Rolando meu próprio usando uma tabela de banco de dados e alguns procedimentos armazenados

Eu queria saber se alguém tem alguma sugestão para isso - ou se alguém fez algo semelhante e tem conselhos sobre o que fazer / evitar. Eu percebo que cada situação é diferente, mas neste caso eu acho que os meus requisitos filas são muito genérico, então eu adoraria ouvir os pensamentos de outra pessoa sobre a melhor maneira de fazer isso.

Desde já, obrigado,

John

Publicado 27/08/2009 em 00:55
fonte usuário
Em outras línguas...                            


3 respostas

votos
18

Se você tem Azure em mente, talvez você deve começar em frente Azure como as APIs e semnatics são significativamente diferentes entre filas Azure e qualquer um MSMQ ou SSB.

Uma rápida 3048 metros comparação do MSMQ vs. SSB (Eu vou deixar um costume mesa-como-fila fora de comparação como ele realmente depende de como você implementá-lo ...)

  • Implantação : MSMQ é um componente do Windows, SSB é um compoenent SQL. SSB requer uma instância do SQL para armazenar qualquer mensagem, os clientes de modo disconencted precisam ter acesso a uma instância (pode ser Express). MSMQ requer implantação de MSMQ no cliente (parte do sistema operacional, mas instalar opcional).
  • Programação : MSMQ oferece um canal WCF de pleno direito, apoiado. SSB oferece apenas um canal WCF experimental em http://ssbwcf.codeplex.com
  • Desempenho : SSB será significativamente mais rápido do que MSMQ no modo transacionado. MSMQ será mais rápido se vamos operar em modo untransacted (melhor esforço, não ordenada, entrega)
  • Queriability : filas SSB pode ser uppon selecte-ed (ver qualquer mensagem, SQL completa ADERIR / ONDE / ORDEM / potência GRUPO), filas MSMQ pode ser peeked (apenas mensagem seguinte)
  • Recuperabilidade : filas SSB estão integrados no banco de dados para que eles sejam copiados e restaurados com o banco de dados, mantendo um estado consitent com o estado do aplicativo. Filas MSMQ são apoiadas no backup de arquivos subsytem NT, de modo a manter o backup em sincronia (coerentes) a fila e banco de dados tem que ser suspenso.
  • Transações (uma vez que cada enqueue / dequeue é sempre acompanhado por uma atualização de banco de dados): SSB é totalmente integrado em SQL assim dequeueing e enqueueing são operações transação local. MSMQ é um TM separado (Transaction Manager) para fila / dequeue tem que ser uma operação Distributed Transaction para se inscrever tanto SQL e MSMQ na transação.
  • Gestão e Monitoramento : tanto equaly ruim. Nenhuma ferramenta qualquer.
  • Correlated Mensagens de processamento: SSB pode bloquear o processamento da mensagem correlata por fios concurent via built-in Conversation Grupo de bloqueio .
  • Event Driven : SSB tem Activation para lançar procedimentos armazenados, MSMQ usa ativação do Windows serviço. Semelhante. SSB que tem auto balanceamento de carga capalities devido à forma como WAITFOR (receber) e MAX_QUEUE_READERS interagir.
  • Disponibilidade : SSB pega carona na história alta disponibilidade SQL Server, ele pode trabalhar em um ambiente em cluster miroring ou no banco de dados. MSMQ monta somente a história de clustering do Windows. Database Mirroring é muito mais barato do que o agrupamento como uma solução HA.

Além disso, eu gostaria de acrescentar que SSB e MSMQ diferem significativamente no nível ofthe primitiva eles oferecem: SSB primitiva é uma conversa , enquanto MSMQ primitiva é uma mensagem . Pense TCP vs. semântica UDP.

Respondeu 27/08/2009 em 01:27
fonte usuário

votos
10

Escolha um back-end fila que funciona para você, ou que é mais adequado para o seu ambiente. @Remus deu uma grande comparação entre MSMQ e SSB. MSMQ vai ser o mais fácil de implementar, mas tem algumas limitações notáveis, enquanto SSB vai sentir muito pesada como a sua na outra extremidade do espectro.

Have It Your Way
Para minimizar o retrabalho de você aplicações, abstratos as filas acessar atrás de uma interface, e, em seguida, fornecer uma implementação para o transporte fila que finalmente decidir ir com ele. Quando é hora de se mover para Azure, ou outro transporte fila, você apenas fornecer uma nova implementação de sua interface.

Você começa a controlar a semântica de como você deseja interagir com a fila para dar uma API útil consistente de suas aplicações.

A idéia aproximada poderia ser:

interface IQueuedTransport
{
  void SendMessage(XmlDocument);
  XmlDocument ReceiveMessage();
}

public class MSMQTransport : IQueuedTransport {}
public class AzureQueueTransport : IQueuedTransport {}

Você pode não estar construindo o-all be transporte fila, apenas o que atenda às suas necessidades. Se você trabalha com XML, passar xml. Se você trabalha em matrizes de bytes, passar matrizes de bytes. :)

Boa sorte!
Z

Respondeu 27/08/2009 em 02:13
fonte usuário

votos
0

Use Win32 Mailslots . Eles vão ser confiável em um único servidor, são fáceis de implementar e não requer qualquer software adicional.

Respondeu 03/03/2011 em 00:28
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more