Já falei aqui de outros serviços do Azure, está na hora de falar de Queues, ou filas.

Filas são algo necessário por casusa da natureza do processamento distribuído, que sofre com a latência, e não teria escalabilidade se fosse fortemente consistente. Mais informações em um post que escrevi a alguns meses sobre ACID X Base, que são conceitos opostos para tratamento de atualizações. Entenda o seguinte se não quiser ler porque BASE é quase obrigatório em aplicações na nuvem: precisamos de filas.

E no Azure elas fazem parte do próprio SO, não são serviços adicionais, como o Workflow, ou o SDS.

Uma fila enfilera mensagens. As mensagens no Azure são strings, mas imagino que futuramente isso deve poder conter algum tipo de dado binário. As mensagens geralmente contém informações do tipo “atualize a tabela x com o valor y”, ou “conte o total e atualize a coluna tal”, ou ainda “mande um e-mail se o processamento x já terminou e ainda não teve o e-mail enviado”. Uma fila pode ter mensagens de até 8KB, mas um número infinito de mensagens.

Queues funciona assim: Imagina que você tem dois fornecedores de fila, e eles enfileram 4 mensagens. Assim:

Temos também, como visto acima, dois consumidores de fila, C1 e C2, que vão buscar mensagens na fila. No caso acima, o C1 puxou uma mensagem da fila, a mensagem 1, por 30 segundos. Nestes 30 segundos a mensagem 1 está invisível na fila para todo mundo, mas ainda não foi excluída da fila.

Então o consumidor 2 puxa a mensagem 2 para ele, também por 30 segundos. O C1 ainda processa a mensagem 1. Assim:

Aí o C2 termina de consumir a mensagem 2, e exclui ela da fila. Agora, mesmo o C2 quebrar, a mensagem 2 já foi processada e morreu. Assim:

Então o C1 cai por causa de algum bug ou outro problema. Ele ainda não tinha terminado de processar a mensagem 1. Então os 30 segundos passam, e a mensagem volta a aparecer na fila automaticamente. Assim:

Então o C2 vai puxar uma nova mensagem da fila, e puxa a primeira na ordem, que é a mensagem 1, que vai agora ser processada pelo C2. Assim:

Dessa forma, a mensagem 1 tem garantia de processamento ao menos uma vez. O problema está nesse “ao menos”. Isso significa que ela pode ser processada mais que uma vez? Significa. Quantas vezes? Impossível dizer. Programe-se para que ela possa rodar n vezes, sem deixar o sistema inconsistente. Como? Verificando se ela já rodou, ou algo do tipo. A mensagem pode ser ACID internamente, mesmo se for BASE para o serviço, não se esqueça disso.

Esse processo todo dá garantia de processamento se uma parte do sistema cair.

Ah, quem são os consumidores da fila? Geralmente vão ser worker roles do próprio Azure. Obrigatoriamente? Não, obvio que não. Poderia ser um serviço web? Poderia, mas acho que vai ser um cenário mais incomum.

No próximo eu continuo com exemplos de código, mas concretos.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.