RabbitMQ

Objetivo

Os message brokers foram desenvolvidos pensando que a estrutura de dados de fila era muito utilizada para resolução de vários tipos de casos de uso. Geralmente eram codificados serviços de filas e esses serviços eram hospedados no mesmo servidor que a aplicação ou utilizava-se as estruturas rodando direto no código da aplicação, o que era ruim pois em caso de queda do aplicativo ou problema no servidor, as as informações que estavam na fila poderiam se perder.

Com isso foi identificada uma possibilidade de desenvolvimento de uma aplicação robusta que pudesse receber essas mensagens com o objetivo de repassa-las a outros pontos, que são chamados de consumidores, de modo que, não estivesse acoplado à quem enviou a mensagem nem a quem vai receber. Dessa forma os dados podem ser armazenados temporáriamente em algum banco separado até que a mensagem seja repassada.

Outras necessidades foram adicionadas, confirmação de recebimento da mensagem e implementação utilizando um protocolo diferente mais aderente a essa necessidade no exemplo do RabbitMQ utiliza-se o protocolo AMQP

Em resumo utilizam-se protocolos que não precisam aguardar resposta, protocolos criados para funcionamento assincrono, que é diferente do protoclo HTTP por exemplo que aguarda uma resposta do servidor.

Mas podemos encerrar com uma questão interessante mesmo o AMQP sendo considerado um protocolo assíncrono, no caso dos brokers ele tem garantia de entrega da mensagem ou seja, para que a mensagem seja confirmada (ack) é necessário avisar o produtor, então ésse é um processo interno que é síncrono. Curioso né ...