Filas contra tabelas em sistemas de mensagens [fechados

Question

Eu tenho experimentado os lados bons e ruins dos sistemas de mensagens em ambientes de produção reais, e devo admitir que uma mesa ou esquema bem organizado de mesas simplesmente bate toda vez que qualquer outra forma de fila de mensagens, porque:

1. Os dados são permanentemente armazenados em uma tabela. Eu já vi tantos aplicativos Java (JMS) que perdem ou desaparecem mensagens a caminho de exceções não capturadas ou outros bugs.
2. As filas tendem a se encher. O armazenamento de banco de dados é praticamente infinito.
3. As tabelas são facilmente acessíveis, enquanto você precisa usar instrumentos esóticos para ler em uma fila.

Qual é a sua opinião sobre cada abordagem?

Answer 1

A frase bate sempre Depende totalmente do que seus requisitos deveriam começar. Certamente não vai vencer todas as vezes para todos.

Se você está criando um único sistema que já está usando um banco de dados, não possui requisitos de rendimento de desempenho muito alto e não precisa se comunicar com outras equipes ou sistemas, provavelmente está certo.

Para coisas simples e baixas, principalmente com um único material de rosca, o banco de dados é uma alternativa totalmente fina às filas de mensagens.

Onde uma fila de mensagens brilha é quando

• Você deseja um balanceador de carga de alto desempenho, altamente concorrente e escalável para poder processar dezenas de milhares de mensagens por segundo simultaneamente em muitos servidores/processos (usando uma tabela de banco de dados que você terá sorte em processar algumas centenas por segundo e processando com múltiplos Os threads são muito difíceis, pois um processo tenderá a bloquear a tabela de filas de mensagens)
• Você precisa se comunicar entre diferentes sistemas usando bancos de dados diferentes (portanto, não precisa distribuir acesso ao seu banco de dados de sistemas para outras pessoas em diferentes equipes etc.

Para sistemas simples com um único banco de dados, equipe e requisitos de desempenho bastante modestos - com certeza use um banco de dados. Use a ferramenta certa para o trabalho etc.

No entanto, onde as filas de mensagens brilham em grandes organizações, onde há muitos sistemas que precisam se comunicar (e, portanto, você não deseja que um banco de dados de negócios seja um ponto central de fracasso ou lugar da versão inferno) ou quando você tem Requisitos de alto desempenho.

Em termos de desempenho, uma fila de mensagens sempre vence uma tabela de banco de dados - como filas de mensagens são projetadas especificamente para o trabalho e não confiam em travas de tabela pessimistas (necessárias para uma implementação de banco de dados de uma fila - para fazer o balanceamento de carga) e Boas filas de mensagens serão executadas no carregamento ansioso de mensagens para evitar a sobrecarga da rede de um banco de dados.

Da mesma forma - você nunca usaria um banco de dados para fazer o balanceamento de cargas de solicitações HTTP em seus servidores da Web - pois seria muito lento - se você tiver requisitos de alto desempenho para o seu balanceador de carga, também não usaria um banco de dados.

Answer 2

Eu usei as tabelas primeiro e depois refator a uma fila de msg completa quando (e se) há razão - o que é trivial se o seu design for razoável.

Os maiores benefícios são a.) É mais fácil (b. É uma trilha de auditoria melhor, porque você tem outras tabelas para se juntar, c.) Se você conhece as ferramentas do banco de dados muito bem, elas são mais fáceis de usar do que as ferramentas da fila de mensagens , d.) Geralmente, é um pouco mais fácil configurar um ambiente de teste/dev em um contexto que já existe para o seu aplicativo (se a mesma familiaridade se aplicar).

Ah, e e.) Para talvez você e outros, não é outro produto para aprender, instalar, configurar, administrar e apoiar.

Impe, é igualmente confiável, desconectado e você pode converter se precisar de mais escaláveis.

Answer 3

1. Os dados são permanentemente armazenados em uma tabela. Eu já vi tantos aplicativos Java (JMS) que soltam ou desaparecem mensagens a caminho de exceções ou outros bugs não capturados.

   Qual implementação do JMS? A Sun vende uma fila confiável que não pode perder mensagens. Talvez você tenha acabado de comprar um produto compatível com JMS brega. O MQ da IBM é extremamente confiável e existem bibliotecas JMS para acessá -lo.

2. As filas tendem a se encher. O armazenamento de banco de dados é praticamente infinito.

   Ummm ... se sua fila se enche, parece que algo está quebrado. Se seus aplicativos travarem, isso não é uma coisa boa, e as filas têm pouco a ver com isso. Se você comprou uma implementação JMS muito ruim, posso ver onde você pode estar descontente com isso. É um mercado competitivo. Encontre um gerente de fila melhor. O JCAPS da Sun tem um bom gerente de filas, anteriormente a fila de mensagens Seebeyond.

3. As tabelas são facilmente acessíveis, enquanto você precisa usar instrumentos esóticos para ler em uma fila.

   Isso não se encaixa na minha experiência. As tabelas são acessadas por meio desse "outro idioma" peculiar (SQL) e exige que eu esteja ciente dos mapeamentos de estrutura de tabelas a objetos e mapeamentos de tipo de dados de varchar2 para string. Além disso, tenho que usar algum tipo de camada de acesso (JDBC ou um ORM que usa JDBC). Isso parece muito, muito complexo. Uma fila é acessada por meio de messageConsumers e MessageProducers usando envios e recebimentos simples.

Answer 4

Parece que os problemas que você experimentou não são inerentes às mensagens, mas são artefatos de sistemas de mensagens mal implementados. A construção de sistemas de mensagens é mais difícil do que a criação de sistemas de banco de dados? Sim, se tudo o que você faz é criar sistemas de banco de dados.

• Perder mensagens para exceções não capturadas? Isso dificilmente é culpa da fila de mensagens. Os aplicativos que você está usando são mal projetados. Eles estão removendo mensagens da fila antes de o processamento ser concluído. Eles não estão usando transações ou diários.
• As filas de mensagens são preenchidas enquanto o armazenamento de banco de dados é "praticamente infinito"? Você fala como se gerenciar o espaço em disco fosse algo que os bancos de dados não exigiam. Os servidores da fila de mensagens exigem administração, assim como os servidores de banco de dados.
• Instrumentos esotéricos para ler de uma fila? Talvez se você encontrar métodos assíncronos esotéricos. Talvez se você encontrar serialização e deserialização esotérica. (Pelo menos, essas são as coisas que achei esotéricas quando estava aprendendo mensagens. Como muitas tecnologias aparentemente esotéricas, elas são realmente muito mundanas quando você as entende, e entendê-las é uma parte importante da educação do desenvolvedor experiente.)

Aspectos das mensagens que tornam superior aos bancos de dados:

• Processamento assíncrono. As filas de mensagens notificam os processos de espera quando novas mensagens chegarem. Para realizar essa funcionalidade em um banco de dados, os processos de espera precisam pesquisar o banco de dados.
• Separação de preocupações. O canal de comunicação é dissociado dos detalhes da implementação do conteúdo da mensagem. Somente o remetente e o receptor precisam saber alguma coisa sobre o formato do fluxo de dados em uma determinada mensagem.
• Tolerância ao erro.. As mensagens podem funcionar quando as conexões entre os servidores são intermitentes. As filas de mensagens podem armazenar mensagens localmente e apenas encaminhá -las para servidores remotos quando a conexão estiver ativa.
• Integração de sistemas. No mundo do Windows, pelo menos, as mensagens são incorporadas ao sistema operacional. Ele usa o modelo de segurança do sistema operacional, é gerenciado através das ferramentas do sistema operacional etc.

Se você não precisa dessas coisas, provavelmente não precisa de mensagens.

Aqui está um exemplo simples de um aplicativo para mensagens: estou construindo um sistema no momento em que os usuários, distribuídos em várias redes, estão inserindo conjuntos bastante intrincados de transações que são usadas para produzir saída impressa. A geração de saída é computacionalmente cara e não faz parte do seu fluxo de trabalho; Ou seja, os usuários não se importam quando a saída é gerada, apenas isso.

Por isso, serializamos as transações em uma mensagem e a deixamos em uma fila. Um processo em execução em um servidor pega mensagens da fila, produz a saída e armazena a saída em um sistema de imagem.

Se usássemos um banco de dados como nosso armazenamento de mensagens, teríamos que criar um esquema para armazenar um formato de transação que agora apenas o remetente e o receptor se preocupem, precisamos garantir que todas as estações de trabalho da rede tivessem permanente Conexões persistentes com o servidor de banco de dados, não teríamos capacidade para distribuir essa carga de transações em vários servidores, e nosso servidor de saída teria que consultar o banco de dados milhares de vezes por dia esperando para ver se havia novos trabalhos para processar.

Answer 5

As filas fornecem mensagens confiáveis. A natureza de loja e encaminhamento e desconectada da fila o torna muito mais escalável do que os bancos de dados, sem mencionar mais robustos.

E as filas não devem realmente ser usadas para armazenamento permanente de informações - é melhor pensar nelas como caixas de entrada temporárias, diferentemente dos bancos de dados.