ActiveMQ ou RabbitMQ ou ZeroMQ ou [fechado]

Gostaríamos de ouvir qualquer experiência com os prós e contras do ActiveMQ vs RabbitMQ vs ZeroMQ. Informações sobre outras filas de mensagens interessantes também são bem-vindas.

Edit: Minha resposta inicial teve um forte foco no AMQP. Decidi reescrevê-lo para oferecer uma visão mais ampla sobre o tópico.

Essas três tecnologias de mensagens têm abordagens diferentes na criação de sistemas distribuídos:

O RabbitMQ é uma das principais implementações do protocolo AMQP (junto com o Apache Qpid). Portanto, implementa uma arquitetura do broker, o que significa que as mensagens são enfileiradas em um nó central antes de serem enviadas aos clientes. Essa abordagem torna o RabbitMQ muito fácil de usar e implantar, porque cenários avançados como roteamento, balanceamento de carga ou enfileiramento de mensagens persistente são suportados em apenas algumas linhas de código. No entanto, também o torna menos escalável e "mais lento" porque o nó central adiciona latência e os envelopes de mensagens são muito grandes.

O ZeroMq é um sistema de mensagens muito leve, especialmente projetado para cenários de alto rendimento / baixa latência, como o que você pode encontrar no mundo financeiro. O Zmq suporta muitos cenários avançados de mensagens, mas, ao contrário do RabbitMQ, você precisará implementar a maioria deles combinando várias partes da estrutura (por exemplo: soquetes e dispositivos). O Zmq é muito flexível, mas você terá que estudar as 80 páginas ou mais do guia (que eu recomendo a leitura para qualquer um que escreva um sistema distribuído, mesmo que você não use o Zmq) antes de poder fazer algo mais complicado do que enviar mensagens entre 2 pares.

ActiveMQ está no meio do caminho. Como o Zmq, ele pode ser implementado com topologias de broker e P2P. Como o RabbitMQ, é mais fácil implementar cenários avançados, mas geralmente à custa do desempenho bruto. É o canivete suíço de mensagens :-).

Finalmente, todos os 3 produtos:

• possui APIs de cliente para as linguagens mais comuns (C ++, Java, .Net, Python, Php, Ruby, ...)
• tem documentação forte
• são ativamente suportados

Por que você sentiu falta de Sparrow , Starling , Kestrel , Amazon SQS , Beanstalkd , Kafka , IronMQ ?

Servidores da fila de mensagens

Os servidores da fila de mensagens estão disponíveis em vários idiomas, Erlang (RabbitMQ), C (beanstalkd), Ruby (Starling ou Sparrow), Scala (Kestrel, Kafka) ou Java (ActiveMQ). Uma breve visão geral pode ser encontrada aqui

Pardal

• escrito por Alex MacCaw
• Sparrow é uma fila leve escrita em Ruby que "fala memcache"

Estorninho

• escrito por Blaine Cook no Twitter
• Starling é um servidor de fila de mensagens baseado em MemCached
• escrito em Ruby
• armazena trabalhos na memória (fila de mensagens)
• documentação: alguns bons tutoriais, por exemplo, o railscast sobre starling e workling ou esta postagem no blog sobre starling

Francelho

• escrito por Robey Pointer
• Clone de Starling escrito em Scala (um porto de Starling de Ruby para Scala)
• As filas são armazenadas na memória, mas no disco conectado

RabbitMQ

• RabbitMQ é um servidor de fila de mensagens em Erlang
• armazena trabalhos na memória (fila de mensagens)

Apache ActiveMQ

• ActiveMQ é um intermediário de mensagens de código aberto em Java

Beanstalkd

• escrito por Philotic, Inc. para melhorar o tempo de resposta de um aplicativo do Facebook
• serviço de fila de trabalho na memória, principalmente escrito em C
• Docu: http://nubyonrails.com/articles/about-this-blog-beanstalk-messaging-queue

Amazon SQS

• Serviço de fila simples da Amazon

Kafka

• Escrito no LinkedIn em Scala
• Usado pelo LinkedIn para descarregar o processamento de todas as páginas e outras visualizações
• O padrão é usar persistência, usa cache de disco do SO para dados quentes (possui taxa de transferência mais alta que qualquer uma das opções acima com persistência ativada)
• Suporta processamento on-line e off-line

ZMQ

• A biblioteca de soquetes que atua como uma estrutura de simultaneidade
• Mais rápido que o TCP, para produtos em cluster e supercomputação
• Carrega mensagens entre inproc, IPC, TCP e multicast
• Conecte N-a-N via fanout, pubsub, pipeline, solicitação-resposta
• E / S assíncrona para aplicativos de passagem de mensagens multicore escalonáveis

EagleMQ

• EagleMQ é um gerenciador de filas de código aberto, alto desempenho e leve.
• Escrito em C
• Armazena todos os dados na memória e suporta persistência.
• Tem seu próprio protocolo. Oferece suporte ao trabalho com filas, rotas e canais.

IronMQ

• IronMQ
• Escrito em Go
• Serviço de fila totalmente gerenciado
• Disponível tanto na versão em nuvem quanto no local

Espero que isso seja útil para nós. fonte

Mais informações do que você gostaria de saber:

http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes

ATUALIZAR

Apenas elaborando o que Paulo acrescentou no comentário. A página mencionada acima está morta após 2010, então leia com uma pitada de sal. Muitas coisas foram alteradas em 3 anos.

Realmente depende do seu caso de uso.

Comparar 0MQ com ActiveMQ ou RabbitMQ não é justo. ActiveMQ e RabbitMQ são sistemas de mensagens que requerem instalação e administração. Eles oferecem featurewise muito mais que o ZeroMQ. Eles têm filas persistentes reais, suporte para transações etc.

ZeroMQ é uma implementação de soquete leve e orientada a mensagens. Também é adequado para programação assíncrona em processo. É possível executar um "Sistema de Mensagens Corporativas" no ZeroMQ, mas você teria que implementar muito por conta própria.

Assim:

ActiveMQ, RabbitMQ, Websphere MQ e MSMQ são "Filas de Mensagens Corporativas"

ZeroMQ é uma biblioteca IPC orientada a mensagens.

Há uma comparação entre o RabbitMQ e o ActiveMQ aqui . Pronto para uso, o ActiveMQ está configurado para garantir a entrega da mensagem - o que pode deixar a impressão lenta em comparação com sistemas de mensagens menos confiáveis. Você sempre pode alterar a configuração do desempenho, se desejar, e obter pelo menos o mesmo desempenho que qualquer outro sistema de mensagens. Pelo menos você tem essa opção. Há muitas informações nos fóruns e nas Perguntas frequentes do ActiveMQ para configuração de escala, desempenho e alta disponibilidade. Além disso, o ActiveMQ oferecerá suporte ao AMQP 1.0 quando a especificação for finalizada, junto com outros formatos de conexão, como STOMP.

Outra vantagem do ActiveMQ é o projeto Apache, para que haja diversidade na comunidade de desenvolvedores - e não esteja vinculado a uma empresa.

Eu não usei o ActiveMQ ou o RabbitMQ, mas usei o ZeroMQ. A grande diferença que vejo entre ZeroMQ e ActiveMQ etc. é que 0MQ é sem corretor e não possui confiabilidade embutida para entrega de mensagens. Se você está procurando uma API de mensagens fácil de usar que suporta muitos padrões, transportes, plataformas e ligações de idiomas, o 0MQ definitivamente vale a pena dar uma olhada. Se você está procurando uma plataforma de mensagens completa, o 0MQ pode não ser o ideal.

Veja www.zeromq.org/docs:cookbook para muitos exemplos de como o 0MQ pode ser usado.

Utilizo 0MQ com êxito para transmitir mensagens em um aplicativo de monitoramento de uso de eletricidade (consulte http://rwscott.co.uk/2010/06/14/currentcost-envi-cc128-part-1/ )

Estou usando zeroMQ. Eu queria um sistema simples de transmissão de mensagens e não precisava da complicação de um corretor. Eu também não quero um grande sistema corporativo orientado para Java.

Se você deseja um sistema simples e rápido e precisa suportar vários idiomas (eu uso C e .net), recomendo analisar o 0MQ.

Só posso adicionar meus 2 centavos sobre o ActiveMQ, mas esse é um dos mais populares:

O idioma em que você deseja escrever pode ser importante. Embora o ActiveMQ tenha um cliente para a maioria, sua implementação em C # está longe de ser concluída em comparação com a Java Library.

Isso significa que algumas funcionalidades básicas são esquisitas (protocolo de failover que ... bem ... falha em alguns casos, não há suporte para reenvio) e outras simplesmente não existem. Como o .NET não parece ser tão importante para o projeto, o desenvolvimento é bastante lento e não parece haver nenhum plano de lançamento. O tronco geralmente está quebrado; portanto, se você considerar isso, poderá contribuir com o projeto se quiser que as coisas avancem.

Depois, há o próprio ActiveMQ, que possui muitos recursos interessantes, mas também alguns problemas muito estranhos. Usamos a versão Fuse (Progress) do activemq por razões de estabilidade, mas mesmo assim existem alguns "bugs" estranhos que você deseja manter em mente:

• Corretores que param de enviar mensagens em algumas ocasiões
• Erros de diário que fazem a fila mostrar mensagens que não estão mais lá (elas não são entregues ao consumidor, mas ainda assim)
• A prioridade ainda não está implementada (está na lista de problemas desde o início do tipo humano)
• etc etc.

Em suma, é um produto muito bom se você pode conviver com seus problemas:

A) não tem medo de se envolver ativamente ao usar o .NET
B) desenvolve em java ;-)

ZeroMQ é realmente com zero filas! É realmente um erro! Não há filas, tópicos, persistência, nada! É apenas um middleware para APIs de soquetes. Se é o que você está procurando! caso contrário, esqueça! não é como activeMQ ou rabbitmq.

Há uma comparação dos recursos e desempenho do RabbitMQ ActiveMQ e QPID fornecidos em
http://bhavin.directi.com/rabbitmq-vs-apache-activemq-vs-apache-qpid/

Pessoalmente, eu tentei todos os três acima. O RabbitMQ é o melhor desempenho para mim, mas não possui opções de failover e recuperação. O ActiveMQ tem mais recursos, mas é mais lento.

Atualização: O HornetQ também é uma opção que você pode procurar, é a Reclamação JMS, uma opção melhor que o ActiveMQ, se você estiver procurando por uma solução baseada em JMS.

Escrevi sobre minha experiência inicial em relação a AMQP, Qpid e ZeroMQ aqui: http://ron.shoutboot.com/2010/09/25/is-ampq-for-you/

Minha opinião subjetiva é que o AMQP é bom se você realmente precisa dos recursos de mensagens persistentes e não está muito preocupado com o fato de o corretor ser um gargalo. Além disso, o cliente C ++ está ausente no AMQP (o Qpid não ganhou meu suporte; no entanto, não tenho certeza sobre o cliente ActiveMQ), mas talvez esteja em andamento. ZeroMQ pode ser o caminho contrário.

Eu uso o ActiveMQ em um ambiente de produção há cerca de 3 anos. Enquanto realiza o trabalho, alinhar versões das bibliotecas clientes que funcionam corretamente e são livres de erros pode ser um problema. No momento, estavam procurando fazer a transição para o RabbitMQ.

Há alguma discussão nos comentários desta postagem no blog , sobre o Twitter escrever sua própria fila de mensagens, o que pode ser interessante.

Steve fez testes extensivos de carga e estresse do ActiveMQ, RabbitMQ etc. O ActiveMQ é realmente muito lento (muito mais lento que o Kestrel), o RabbitMQ trava consistentemente com muitos produtores e poucos consumidores.

Você provavelmente não terá uma carga semelhante ao Twitter inicialmente :)

Poucos aplicativos têm tantas configurações de ajuste quanto o ActiveMQ. Alguns recursos que destacam o ActiveMQ são:

Tamanho de pré-busca configurável. Rosca configurável. Failover configurável. Notificação administrativa configurável para produtores. ... detalhes em:

http://activemq.net/blog http://activemq.apache.org

Abie, tudo se resume ao seu caso de uso. Em vez de confiar na conta de outra pessoa do caso de uso, fique à vontade para postar seu caso de uso na lista rabbitmq-discuss. Pedir no twitter também lhe dará algumas respostas. Muitas felicidades, alexis

Sobre o ZeroMQ, também conhecido como 0MQ, como você já deve saber, é o que recebe mais mensagens por segundo (eram cerca de 4 milhões por segundo no servidor de referência na última vez que verifiquei), mas como você já deve saber, o documentação não existe. Você terá dificuldade em descobrir como iniciar o (s) servidor (es), muito menos como usá-lo. Eu acho que é em parte porque ninguém contribuiu com o 0MQ ainda.

Diverta-se!

Se você também estiver interessado em implementações comerciais, dê uma olhada no Nirvana em meus canais .

O Nirvana é muito utilizado no setor de Serviços Financeiros para plataformas de distribuição e preços em larga escala, com baixa latência.

Há suporte para uma ampla variedade de linguagens de programação de clientes nos domínios corporativo, web e móvel.

Os recursos de cluster são extremamente avançados e vale a pena examinar se o balanceamento de HA ou carga transparente é importante para você.

O Nirvana é gratuito para download para fins de desenvolvimento.