Fila de mensagens. Banco de Dados vs MQ Dedicado

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.

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.

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.

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.

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.

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.