Fila de mensagens. Banco de Dados vs MQ Dedicado

17

Estou buscando conselhos sobre o enfileiramento de mensagens. Temos requisitos para que "trabalhos" sejam postados em uma fila de mensagens.

A sugestão original era apenas usar uma instância do SQL Server e processar mensagens a partir dela. Tudo o que li na internet sugere que o uso de um banco de dados para uma fila de mensagens não é uma solução escalável. Por esse motivo, foi sugerida a idéia de usar o RabbitMQ ou outro MQ de terceiros.

A outra coisa a levar em consideração é que o requisito para "processamento de trabalho" não será menor que 30 segundos; portanto, o processo que faz o trabalho pesquisará o banco de dados a cada 30 segundos. Para mim, isso não parece tão ruim e provavelmente funcionaria bem sem adicionar uma grande carga ao banco de dados.

Já temos um banco de dados em nossos clientes que poderíamos usar para isso, para que ele não adicione muito suporte extra necessário para nossos clientes, enquanto que se adicionássemos um MQ de terceiros, haveria suporte extra para a configuração de rede, etc. considerável, dado que há muitos usuários.

A outra opção que eu estava considerando era permitir que os usuários escolhessem entre eles. Se eles forem um usuário pequeno, a solução Sql Server ficará bem, mas se eles forem usuários maiores, permitiremos que eles configurem uma solução MQ de terceiros.

Não estou vendendo nenhuma solução, estou me perguntando se alguém tem algo que eu deva considerar ou aconselhar.

user1653400
fonte
1
Esses 'trabalhos' são um 'alerta e esqueça' ou o processo terá que ligar de volta para casa para que o servidor saiba o status desse trabalho?
c_maker
Quão escalável ele precisa ser? Você está executando algumas centenas de milhares de mensagens por dia ou vários bilhões?
Blrfl
Obrigado pelos comentários: existe um requisito para o trabalho ser marcado como incompleto (eles são considerados completos, a menos que sejam marcados como incompletos / com falha). Eu pensaria que não mais que 20.000 mensagens por dia. Provavelmente apenas alguns milhares.
user1653400
Use a ferramenta mais apropriada para o trabalho. Se você precisar de uma fila de mensagens, use uma fila de mensagens, não um banco de dados. Eu já vi pessoas usando tabelas de banco de dados como filas de mensagens antes e considero isso um anti-padrão. Você pode usar uma chave de fenda como martelo, mas um martelo funciona melhor se você precisar pregar um prego. Na maioria das vezes, quando as pessoas fazem isso, é porque entendem bancos de dados, mas não filas de mensagens.
Jesper
Há alguns bons ponteiros aqui: rusanu.com/2010/03/26/using-tables-as-queues
Michael Green

Respostas:

18

Tudo o que li na internet sugere que o uso de um banco de dados para uma fila de mensagens não é uma solução escalável.

A realidade frequentemente ignorada pela multidão " não use X porque não é escalável " (o link contém uma linguagem que alguns podem achar questionável) é que a escala nem sempre é importante. Eu chegaria ao ponto de dizer que, se você olhar para todas as aplicações na face do planeta em conjunto, a escala raramente é importante.

Seu comentário cita uma taxa de 20.000 mensagens diárias, o que significa que você precisa suportar uma taxa média de 0,23 mensagens por segundo (uma a cada 4,3 segundos). Se o seu projeto tiver duas ordens de magnitude mais bem-sucedidas do que o esperado, seus requisitos passam para o processamento de 23 mensagens por segundo, tarefa que eu ficaria muito confortável em dar ao meu celular de quatro anos ou a um Raspberry. Pi. Isso ainda não é um aplicativo de alta escala, mesmo se você seguir outras ordens de magnitude além disso.

Eu assisti (felizmente, do lado de fora) os projetos terminarem mal porque eles gastaram muito tempo muito cedo obcecando com a escala que não iria acontecer ou com pouco tempo nela e foram esmagados pela escala que acabou. Como todo o resto, existe um meio feliz. Se você acha que o dimensionamento grande para o seu aplicativo é uma possibilidade realista, não deve ser difícil justificar os negócios para fazer a pequena quantidade de trabalho extra para criar uma abstração suficiente em torno de peças não escalonáveis ​​e de baixo custo para implantar agora . Isso significa que , mais tarde , se surgir uma necessidade de escala, você tem uma maneira (e possivelmente a receita) de fazer a substituição por atacado dessas peças sem precisar repensar o sistema inteiro.

Embora o volume de mensagens do seu aplicativo não faça com que um banco de dados ou um sistema de enfileiramento de mensagens exagere, mesmo em um hardware modesto, você provavelmente tem outros requisitos para lidar com as transações de mensagens que tornam uma ou outra uma escolha melhor. Esses requisitos são o que você deve avaliar.

Blrfl
fonte
Eu tenho um banco de dados com milhões de transações feitas diariamente. que eu preciso processar através de sms. Atualmente, estou usando a tabela sql como enfileiramento, mas fico preso ao coletar uma grande quantidade de dados. Não posso usar o MQ porque preciso encaminhar meus sms com base na configuração em tempo real. Se eu usar o MQ, ele não usará a configuração atual do cliente. pois estamos mudando de provedor no back-end quando algum provedor falha ao processar. Então, cara, o que me sugere no meu cenário?
Mayur Rathod
@mayurRathod Esse tópico parece forragem para uma pergunta separada. Fale com cuidado, porque uma solicitação de ferramentas ou recursos específicos será fechada como fora de tópico.
Blrfl
9

As filas de mensagens realmente surgem quando você tem muitas delas e roteia mensagens entre elas, fanout para mais de um consumidor, etc.

Se você tiver apenas uma única fila de tarefas que deseja processar 'off-line', uma tabela SQL funcionará perfeitamente.

Não se esqueça de garantir que você tenha alguma maneira de marcar trabalhos em andamento, limpando os antigos e alertando quando o sistema parar. Porém, para uma única fila, gerenciar manualmente essas coisas será menos trabalhoso do que manter uma solução de fila separada.

Ewan
fonte
5

Como outros já mencionaram escala, provavelmente não é importante aqui. O problema com o uso de dois mecanismos de armazenamento diferentes é a integridade transacional.

Se você estiver com uma fila de mensagens dedicada, precisará escolher um dos seguintes em caso de falha.

  1. Permitir que os dados possam estar em mb, mas não em db
  2. Permitir que os dados possam estar em db, mas não em mb
  3. Configurar transações consolidadas ou consolidadas em duas fases entre db e mq, o que pode ser complicado

Todos esses problemas desaparecem se você salvar os dados em um único local usando uma transação normal. Por esse motivo, usar o db como uma fila de tarefas é uma solução perfeitamente adequada.

Esben Skov Pedersen
fonte
4

Por praticidade, os principais motivos para eu usar uma fila de mensagens são:

  • Não precisei reinventar a roda. Projetar até a fila de mensagens mais simples usando o banco de dados requer pelo menos algumas horas de reflexão, algumas horas de codificação e assim por diante. Comparado à implementação de uma fila de mensagens, o tempo necessário para configurar e / ou automatizar a configuração é trivial
  • As filas de mensagens têm uma interface agradável e clara para produtor e consumidor. Esta é provavelmente a coisa mais importante ao escrever um aplicativo. Sem a interface, as filas de mensagens são basicamente apenas uma coleta de dados
  • As filas de mensagens fornecem mais recursos que podem ser necessários no futuro

Quanto a permitir que os usuários escolham, esse é realmente um detalhe de implementação com o qual os usuários não devem se preocupar. Os usuários devem obter a mesma interface e não deve haver diferença para os usuários se o banco de dados ou a fila de mensagens for usada. Depois que um único design é definido, uma escolha provável para os usuários é quantos nós precisam ser implantados para acomodar suas necessidades.

imel96
fonte
1

Criei uma solução de fila de mensagens Mssql que pode lidar com operações de 20k por segundo, de acordo com um teste de desempenho, e precisamos de 10 / s na maioria das vezes. Eu acho que o fato de você poder realmente ter prioridade incorporada é um recurso que falta na fila de mensagens dedicada. E este foi um requisito importante no meu caso.

Stephan Ryer
fonte