Em primeiro lugar, os sistemas de mensagens "mais antigos" (MQ) são mais antigos na implementação, mas são mais novos na ideia de engenharia de: filas persistentes transacionais . Scala Actors e Akka podem ser uma implementação mais recente, mas são construídos em um modelo de simultaneidade mais antigo de Actors.
Os dois modelos, entretanto, acabam sendo muito semelhantes na prática porque ambos são baseados em mensagens de evento: Veja minha resposta para RabbitMQ vs Akka .
Se você pretende codificar apenas para JVM, Akka provavelmente é uma boa escolha. Caso contrário, eu usaria RabbitMQ.
Além disso, se você é um desenvolvedor Scala, então Akka deve ser um acéfalo. No entanto, as ligações Java da Akka não são muito Java e requerem conversão devido ao sistema de tipos do Scala.
Também em Java as pessoas normalmente não fazem objetos imutáveis, o que eu recomendo que você faça para mensagens. Consequentemente, é muito fácil em Java fazer algo acidentalmente usando Akka que não será escalonado (usando objetos mutáveis para mensagens, contando com um estado de retorno de chamada de encerramento estranho). Com o MQ, isso não é um problema porque as mensagens são sempre serializadas ao custo da velocidade. Com Akka eles geralmente não são.
Akka também se adapta melhor com uma grande quantidade de consumidores do que a maioria do MQ. Isso ocorre porque para a maioria dos clientes MQ (JMS, AMQP), cada conexão de fila requer um encadeamento ... portanto, muitas filas == muitos encadeamentos em execução permanente. No entanto, este é principalmente um problema do cliente. Acho que o ActiveMQ Apollo tem um despachante sem bloqueio que supostamente corrige esse problema para AMQP. O cliente RabbitMQ possui canais que permitem combinar vários consumidores, mas ainda existem problemas com um grande número de consumidores, potencialmente causando deadlocks ou conexões morrendo, então geralmente mais threads são adicionados para evitar esse problema.
Dito isso, o remoting da Akka é bastante novo e provavelmente ainda não oferece todas as garantias de mensagens confiáveis e QoS que as filas de mensagens tradicionais fornecem (mas isso está mudando todos os dias). Também é geralmente ponto a ponto, mas eu acho que suporta servidor a ponto, que geralmente é o que a maioria dos sistemas MQ faz (ou seja, ponto único de falha), mas há sistemas MQ que são ponto a ponto (RabbitMQ é servidor to-peer).
Finalmente RabbitMQ e Akka realmente formam um bom par. Você pode usar o Akka como um wrapper para o RabbitMQ, especialmente porque o RabbitMQ não o ajuda a lidar com o consumo de mensagens e rotear as mensagens localmente (em uma única JVM).
Quando escolher Akka
- Tenha muitos consumidores (pense em milhões).
- Necessita de baixa latência
- Aberto ao modelo de simultaneidade do ator
Sistema de exemplo: um sistema de bate-papo interativo em tempo real
Quando escolher MQ
- Precisa se integrar com muitos sistemas diferentes (ou seja, não JVM)
- A confiabilidade da mensagem é mais importante do que a latência
- Gostaria de mais ferramentas e IU de administrador
- Por causa dos pontos anteriores, é melhor para tarefas de longa duração
- Gostaria de usar um modelo de simultaneidade diferente do Actors
Sistema de exemplo: um sistema de processamento em lote transacional programado
EDITAR com base em comentários preocupados
Presumi que o OP se preocupava com o processamento distribuído que tanto o Akka quanto o Message Queues podem controlar. Presumi que ele estava falando sobre a Akka distribuída . Usar o Akka para simultaneidade local é uma comparação comparativa com a maioria das filas de mensagens . Digo mais porque você pode aplicar o modelo de fila de mensagens localmente como um modelo de simultaneidade (ou seja, tópico, filas, trocas) que a biblioteca Reactor e a reação simples fazem.
Escolher o modelo / biblioteca de simultaneidade certo é muito importante para aplicativos de baixa latência. Uma solução de processamento distribuído, como uma fila de mensagens, geralmente não é ideal porque o roteamento é quase sempre feito através da rede, que é obviamente mais lento do que dentro do aplicativo e, portanto, Akka seria uma escolha superior. No entanto, acredito que algumas tecnologias proprietárias do MQ permitem o roteamento local. Além disso, como mencionei anteriormente, a maioria dos clientes MQ são muito estúpidos sobre threading e não dependem de IO sem bloqueio e têm um thread por conexão / fila / canal ... ironicamente, io sem bloqueio nem sempre é de baixa latência, mas geralmente é mais recurso eficiente.
Como você pode ver, o tópico de programação distribuída e programação simultânea é bastante extenso e muda todos os dias, então minha intenção original não era confundir, mas sim focar em uma área particular de processamento de mensagem distribuída que é o que eu pensei que o OP estava preocupado. Em termos de simultaneidade, pode-se querer focar suas pesquisas na programação "reativa" (RFP / streams), que é um modelo "mais novo", mas semelhante ao modelo de ator e modelo de fila de mensagens, dos quais todos esses modelos podem ser geralmente combinados porque eles são baseados em eventos.