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.
Eu sou novo na fila de mensagens e estava lendo mais sobre o caso de uso real em stackoverflow.com/q/1035949/181870 . Mais tarde, pesquisando tópicos / artigos relacionados à fila de mensagens (JMS em particular), deparei-me com o OpenJMS - uma implementação de código aberto da especificação Java Message Service API 1.1 da Sun Microsystems. O que me surpreende é que não seja abordado / discutido aqui? Eu só queria verificar com a comunidade se o OpenJMS está relacionado a esse tópico / discussão e, se sim, conforme o OP, qualquer experiência com prós e contras do mesmo ajudaria.
Três anos depois, uma observação para as pessoas que navegam por aqui ... pense por que você deseja usar o middleware de enfileiramento de mensagens. Se o motivo for distribuir tarefas em um cluster, consulte o Aipo. Ele opera em um nível de abstração mais alto do que as soluções no estilo MQ, usa o RabbitMQ para mover mensagens, mas possui excelente suporte para semânticas específicas de tarefas.
— 31413 Chris Johnson
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
Embora seja verdade, não tenho certeza se a adoção do AMQP tem forte correlação com a pergunta original. Eu acho que há considerações mais importantes para a escolha de uma fila de mensagens do que o protocolo de conexão subjacente que ela usa.
— 23410 StaxMan
A pergunta não menciona a exigência do AMQP, mas esta resposta está focada no AMQP. Se assumirmos o JMS como um requisito, a resposta seria basicamente o inverso: o ActiveMQ é o mais popular, o RabbitMQ tem algum suporte que provavelmente deve funcionar. Se nenhum protocolo de conexão for assumido: consulte outras respostas.
Tendo trabalhado no RabbitMQ e no ActiveMQ, eu recomendaria que você ficasse longe do ActiveMQ. Os lançamentos são muito problemáticos, e eu não tive problemas com máquinas caindo e vazamentos de memória, etc ... O RabbitMQ, por outro lado, simplesmente funciona. Depois que o pluguei, NUNCA tive que olhar novamente. Apenas faz o que precisa. Se você gosta Eu tenho um tutorial simples RabbitMQ no meu blog jarloo.com/rabbitmq-c-tutorial
Depois de analisar as vagas de emprego do RabbitMQ versus ActiveMQ, o RabbitMQ parece ter muito mais demanda. O ActiveMQ já existe há mais tempo, mas está sendo solicitado pelos empregadores quase o mesmo.
O guia para ZMQ também é realmente um divertido e boa leitura :)
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
escrito por Alex MacCaw
Sparrow é uma fila leve escrita em Ruby que "fala memcache"
escrito por Blaine Cook no Twitter
Starling é um servidor de fila de mensagens baseado em MemCached
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
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 é um servidor de fila de mensagens em Erlang
ActiveMQ é um intermediário de mensagens de código aberto em Java
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
Serviço de fila simples da Amazon
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
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 é um gerenciador de filas de código aberto, alto desempenho e leve.
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.
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
— Andrei Andrushkevich
Você tem alguma idéia / pensamento de adicionar / comentar para minha pergunta feita na área de comentários desta pergunta aqui - stackoverflow.com/questions/731233/… ?
Eles têm gerenciamento de contenção? Sempre achei esse problema nos sistemas de filas. Por exemplo, bloquear um produtor se a fila estiver cheia com base no número de elementos (não nos recursos de memória).
queues.io - Lembre-se de adicionar detalhes que faltam lá vs. aqui.
— asyncwait
Mais informações do que você gostaria de saber:
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.
Acho que esses caras estão pensando em filas erradas - as filas não devem ter 1 (ou mais) por usuário. Eles devem colocar seu trabalho em algumas filas e depois utilizá-lo. caixas de entrada (ou mboxes) para cada usuário.
Michael - quer elaborar um pouco mais? O problema é a entrega em tempo real em um sistema baseado em bate-papo em grupo. Se estou entendendo corretamente, você está falando de um mecanismo de armazenamento durável para mensagens como um terminal (caixa de entrada)? Nesse caso, não cabe à conta, eles querem que o chat seja entregue imediatamente e os clientes sejam assinantes diretos? Tanto quanto eu posso dizer, ter uma tonelada de filas baseadas em tópicos não é um caso de uso otimizado?
Atualização: a página wiki do SecondLife foi escrita em 2009. Até agora, em 2013, muitos dos pontos específicos mencionados sobre as diferentes filas de mensagens que eles investigaram não estavam mais atualizados, devido a melhorias contínuas em todos os MQs. A maioria ou todos os MQs testados estão melhores, em certo sentido, até agora.
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.
ActiveMQ, RabbitMQ, Websphere MQ e MSMQ são "Filas de Mensagens Corporativas"
ZeroMQ é uma biblioteca IPC orientada a mensagens.
— sanosdole
Você pode usar mais de um. rabbitmq.com/blog/2010/10/18/rabbitmq0mq-bridge fala sobre como você pode usar o 0MQ para fazer a ponte entre vários brokers RabbitMQ e criar uma federação pouco acoplada.
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.
Também usando o ZMQ no ambiente C / C ++. Muito rápido. Usando o padrão do intermediário. Um bom ajuste para o nosso aplicativo watch-dog VOIP em tempo real, executando micro-pmts para farms de servidores SIP kamailio. Certamente eu poderia escrever um corretor muito sofisticado usando o ZMQ, mas avaliaria alguns produtos adicionais antes de me comprometer com isso.
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)
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 ;-)
— Noctris
Atualização secundária: há algum tempo, o KahaDB é o armazenamento de persistência padrão do ActiveMQ. No entanto: não é absolutamente estável. Em nossos testes, vimos corrupção de banco de dados (alguns restorable, outros nos custando cerca de 15.000.000 mensagens) cuidado com isso
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.
— Angek
Há uma comparação dos recursos e desempenho do RabbitMQ ActiveMQ e QPID fornecidos em
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
— cobrien
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.
— Charle
Existem exemplos no livro de receitas zeromq.org/docs:cookbook e há um manual api.zeromq.org/zmq.html .
Embora o zmq seja rápido e tenha uma API fácil, lembre-se disso: sem persistência, sem transações. Nenhuma detecção de consumidores falidos ou lentos (as mensagens simplesmente são descartadas sem qualquer notificação ao programa produtor). Nota: zmq não possui servidor, portanto, você não encontrará documentos para iniciar os servidores. Eles têm um servidor proxy, se você precisar de algo assim.
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ê.