Projetando uma arquitetura escalável da fila de mensagens

Recentemente, comecei a aprender as nuances da arquitetura escalonável e corporativa de computadores, e um dos componentes centrais é uma fila de mensagens. Para aprender o máximo possível de qualquer paradigma de programação, estou tentando implementar minha própria versão de um serviço de fila de mensagens.

Até o momento, meu design inicial é executado em um ouvinte de soquete encadeado, mas para impedir que a mesma mensagem seja baixada duas vezes por dois nós de processamento separados, o registro do índice da fila de mensagens é bloqueado quando uma leitura é iniciada e desbloqueado após o registro ter sido efetuado. Atualizada. Como tal, isso nega a necessidade de ser encadeado e significa que há um limite para o tamanho de um sistema escalável com base na velocidade de processamento do servidor em que o serviço da fila de mensagens está sendo executado.

A maneira de contornar isso seria executar o serviço de fila de mensagens em vários servidores, mas isso aumentará a probabilidade de a mesma mensagem ser baixada duas vezes. A única maneira de impedir que esses problemas ocorram seria incluir um retorno de chamada de revogação que (depois que os servidores ou mesmo os encadeamentos em um único servidor sincronizassem suas informações e detectassem tal reemissão) comandaria o nó de processamento para interromper sua trabalho atual e consulte novamente a fila de mensagens para a próxima mensagem, mas, novamente, haveria um teto em que a maior parte do tráfego enviado seria sincronizações e retornos de chamada de revogação, causando um gargalo e retardando o processamento de informações para que um Muitos nós de processamento estariam executando operações nulas e perdendo tempo.

A última maneira em que posso resolver esse problema é fazer com que cada servidor da fila de mensagens (e cada encadeamento em cada servidor) tenha um deslocamento específico para o local na fila que está procurando, mas isso pode ter problemas com base no tipo de aplicativo, especialmente se for necessário que o processamento seja feito em uma ordem específica.

Portanto, tudo o que foi dito, existem projetos de arquitetura de fila de mensagens que possam me mostrar como os serviços existentes de fila de mensagens de nível empresarial evitam esses problemas?

Em resumo:

Este é um problema díficil. Não reinvente a roda.

Existem muitas tecnologias que resolvem a camada da fila de mensagens. Eles incluem

• ZeroMQ
• RabbitMQ
• Apache Kafka
• Redis, com BLPOP ou PUBSUB (perguntei como fazer isso aqui ).
• Outras implementações de AMQP além do RabbitMQ

Eu acho que está fora do escopo discutir os inconvenientes de cada um, não menos importante, porque eu realmente não reivindico o conhecimento necessário para fazer isso bem tosse , não use tosse de coelho .

Mesmo se você não quiser usar nenhuma dessas tecnologias, leia as documentações.

Isso o instruirá sobre os padrões de design possíveis em um sistema. A leitura da documentação do ZeroMQ o instruirá sobre muitas arquiteturas clássicas de enfileiramento de mensagens que eles implementaram graciosamente. Mesmo se você não usar o ZeroMQ, conhecer esses padrões o ajudará a avaliar outras tecnologias de enfileiramento, perguntando se você pode implementar esse padrão lá.

Aprenda sobre o modelo de fila de troca do RabbitMQ / AMQP. O roteamento pode surgir para você - isso é suportado pelo Redis PUBSUB, mas não me lembro de ter sido suportado pelo ZeroMQ - e fanouts são algo que minha loja está usando, embora pouco implementado em uma pesquisa do Memcached (eca!), Por algum tempo .

Como escolher um?

Trabalho em uma startup cujo SLA é típico para um aplicativo Web - algumas interrupções são aceitáveis, desde que possamos restaurar rapidamente o serviço com pouca perda de dados. Não tivemos que pensar em problemas de dimensionamento, como o Twitter ou o Tumblr, por isso não tivemos que pensar em volume de produtividade. Dito isto, se você estiver implementando um SLA semelhante ao meu, essas considerações serão lembradas:

• as bibliotecas cliente realmente funcionam ? É fácil manter uma conexão neles? (ZeroMQ, Redis: sim. RabbitMQ: não).
• é fácil monitorar e gerenciar um console de servidor? (Redis: sim, RabbitMQ: sim, ZeroMQ: não que eu me lembre, mas não o usamos por tanto tempo)
• os clientes suportam filas internas para que ocorra pouca perda de dados em curtas interrupções? (ZeroMQ, Redis: sim. RabbitMQ: não.)

Obviamente, se você estiver trabalhando para, digamos, uma loja de negociação de alta frequência, essas serão suas preocupações menores. Você estará mais disposto a dedicar tempo de desenvolvimento a uma biblioteca do lado do cliente em troca de uma taxa de transferência mais alta no final. Mas estou escrevendo isso mais para avisá-lo de que essas tecnologias tendem a ser comercializadas com base no desempenho delas, não na funcionalidade pronta para uso. Se você é um iniciante na web, está muito mais interessado no que no anterior e, portanto, algo como o Redis, que é mais otimizado para facilitar o uso com bom desempenho do que a dificuldade de usar com ótimo desempenho, provavelmente é um melhor escolha do que RabbitMQ. (Eu realmente não gosto do RabbitMQ).