ActiveMQ ou RabbitMQ ou ZeroMQ ou

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

    Edit: Minha resposta inicial teve um forte foco no AMQP. Eu decidi reescrevê-lo para oferecer uma visão mais ampla sobre o tema.

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

    O RabbitMQ é uma das principais implementações do protocolo AMQP (junto com o Apache Qpid). Portanto, ele implementa uma arquitetura de 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 implementar, porque cenários avançados como roteamento, balanceamento de carga ou enfileiramento persistente de mensagens são suportados em apenas algumas linhas de código. No entanto, ele também o torna menos escalável e “mais lento” porque o nó central adiciona latência e os envelopes de mensagem são bem grandes.

    O ZeroMq é um sistema de mensagens muito leve, especialmente projetado para cenários de alta taxa de transferência / 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ê terá que implementar a maioria deles, combinando várias partes do framework (por exemplo: sockets e dispositivos). O Zmq é muito flexível, mas você terá que estudar as 80 páginas do guia (que eu recomendo ler para alguém que esteja escrevendo o 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.

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

    Finalmente, todos os 3 produtos:

    • tem cliente apis para as linguagens mais comuns (C ++, Java, .Net, Python, Php, Ruby,…)
    • tenha documentação forte
    • são ativamente apoiados

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

    Servidores da fila de mensagens

    Os servidores de 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 Message Queue Server baseado em MemCached
    • escrito em Ruby
    • armazena trabalhos na memory (fila de mensagens)
    • documentação: alguns bons tutoriais, por exemplo, o railscast sobre starling e workling ou este post 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 memory, mas registradas no disco

    RabbitMQ

    • RabbitMQ é um servidor de fila de mensagens em Erlang
    • armazena trabalhos na memory (fila de mensagens)

    Apache ActiveMQ

    • O ActiveMQ é um agente de mensagens de código aberto em Java

    Beanstalkd

    Amazon SQS

    • Serviço de fila simples do Amazon

    Kafka

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

    ZMQ

    • A biblioteca de sockets que age como uma estrutura de simultaneidade
    • Mais rápido que o TCP, para produtos em cluster e supercomputação
    • Transporta mensagens em inproc, IPC, TCP e multicast
    • Conecte N-para-N através do fanout, pubsub, pipeline, solicitação-resposta
    • Asynch I / O para aplicativos escaláveis ​​de transmissão de mensagens em vários núcleos

    EagleMQ

    • O EagleMQ é um gerenciador de filas de software livre, de alto desempenho e leve.
    • Escrito em C
    • Armazena todos os dados na memory e suporta a persistência.
    • Tem seu próprio protocolo. Suporta trabalho com filas, rotas e canais.

    IronMQ

    • IronMQ
    • Escrito em Go
    • Serviço de fila totalmente gerenciado
    • Disponível como versão em nuvem e 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 Paul acrescentou em comentário. A página mencionada acima está morta depois de 2010, então leia com uma pitada de sal. Muitas coisas foram mudadas em 3 anos.

    História da Página Wiki

    Isso realmente depende do seu caso de uso.

    Comparar 0MQ com o ActiveMQ ou o RabbitMQ não é justo. O ActiveMQ e o RabbitMQ são Sistemas de Mensagens que requerem instalação e administração. Eles oferecem muito mais resources do que o ZeroMQ. Eles têm filas persistentes reais, suporte para transactions etc.

    O ZeroMQ é uma implementação leve de soquete orientada para mensagens. Ele também é adequado para programação assíncrona em processo. É possível executar um “Enterprise Messaging System” sobre o 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 mensagem orientada para a biblioteca IPC.

    Há uma comparação entre o RabbitMQ e o ActiveMQ aqui . Fora da checkbox, o ActiveMQ é configurado para garantir a entrega de mensagens – o que pode dar a impressão de que é lento em comparação com sistemas de mensagens menos confiáveis. Você sempre pode alterar a configuração para desempenho se desejar e obter pelo menos um desempenho tão bom quanto qualquer outro sistema de mensagens. Pelo menos você tem essa opção. Há muitas informações nos fóruns e no ActiveMQ FAQ para configuração de dimensionamento, desempenho e alta disponibilidade. Além disso, o ActiveMQ suportará o AMQP 1.0 quando a especificação for finalizada, junto com outros formatos de conexão, como o STOMP.

    Outra vantagem para o ActiveMQ é seu projeto Apache, portanto, há diversidade na comunidade de desenvolvedores – e não está vinculada a uma empresa.

    Eu não usei ActiveMQ ou RabbitMQ mas usei o ZeroMQ. A grande diferença que vejo entre o ZeroMQ e o ActiveMQ, etc., é que o 0MQ não tem broker e não possui confiabilidade para a entrega de mensagens. Se você está procurando uma API de mensagens fácil de usar que suporte muitos padrões de mensagens, transportes, plataformas e ligações de linguagem, então o 0MQ definitivamente vale a pena dar uma olhada. Se você está procurando por uma plataforma de mensagens completa, então o 0MQ pode não se encheckboxr na conta.

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

    Eu usando com sucesso o 0MQ para passar mensagens em um aplicativo de monitoramento de uso de eletricidade (veja http://rwscott.co.uk/2010/06/14/currentcost-envi-cc128-part-1/ )

    Estou usando o zeroMQ. Eu queria um sistema de passagem de mensagens simples e não preciso da complicação de um corretor. Eu também não quero um enorme sistema corporativo orientado a Java.

    Se você quer um sistema rápido e simples e precisa suportar vários idiomas (eu uso C e .net), então eu recomendo olhar para o 0MQ.

    Eu só posso adicionar meus 2 centavos sobre o ActiveMQ, mas desde que este é um dos mais populares:

    A língua que você quer escrever pode ser importante. Embora o ActiveMQ tenha um cliente para a maioria, sua implementação do C # está longe de ser completa em comparação com a Biblioteca Java.

    Isso significa que algumas funcionalidades básicas são escamosas (o protocolo de failover que … bem … falha em alguns casos, não há suporte a novas entregas) e outras simplesmente não estão lá. Como o .NET não parece ser tão importante para o projeto, o desenvolvimento é bastante lento e parece não haver nenhum plano de lançamento. Tronco é freqüentemente quebrado por isso, se você considerar isso, você pode querer considerar contribuir para o projeto, se você quiser que as coisas vão em frente.

    Depois, há o próprio ActiveMQ, que tem muitos resources interessantes, mas também alguns problemas muito estranhos. Usamos a versão Fuse (Progress) do activemq por razões de estabilidade, mas mesmo assim há alguns “bugs” esquisitos que você deve ter em mente:

    • Corretores que param de enviar mensagens em algumas ocasiões
    • Erros no Diário fazendo 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.

    Tudo e todos, é um produto muito bom se você pode viver com seus problemas:

    A) não tem medo de se envolver ativamente ao usar o .NET
    B) desenvolver em java 😉

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

    Há uma comparação dos resources e desempenho do RabbitMQ ActiveMQ e QPID dado 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, de acordo comigo, mas não possui opções de failover e recuperação. O ActiveMQ tem mais resources, mas é mais lento.

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

    Eu escrevi sobre a minha experiência inicial sobre 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 resources de mensagens persistentes e não está muito preocupado que o corretor possa ser um gargalo. Além disso, o cliente C ++ está ausente no momento para o AMQP (o Qpid não ganhou meu suporte; não tenho certeza sobre o cliente do ActiveMQ), mas talvez esteja em progresso. ZeroMQ pode ser o contrário.

    Eu usei o ActiveMQ em um ambiente de produção por cerca de 3 anos agora. Enquanto isso faz o trabalho, alinhar versões das bibliotecas clientes que funcionam corretamente e estão livres de erros pode ser um problema. Estávamos olhando para a transição para o RabbitMQ.

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

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

    Você provavelmente não terá uma carga similar ao Twitter inicialmente, no entanto 🙂

    Poucas aplicações têm tantas configurações de ajuste quanto o ActiveMQ. Alguns resources que destacam o ActiveMQ são:

    Tamanho de pré-busca configurável. Encadeamento configurável. Failover configurável. Notificação administrativa configurável aos 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, sinta-se à vontade para postar seu caso de uso na lista rabbitmq-discuss. Perguntar no twitter vai te dar algumas respostas também. Felicidades, alexis

    Sobre o ZeroMQ aka 0MQ, como você já deve saber, é o que te dará mais mensagens por segundo (eles eram cerca de 4 milhões por segundo em seu servidor de ref na última vez que eu verifiquei), mas como você também já deve saber, o documentação é inexistente. Você terá dificuldade em descobrir como iniciar o (s) servidor (es), e muito menos como usá-los. Eu acho que é em parte porque ninguém contribuiu com o 0MQ ainda.

    Diverta-se!

    Se você também está interessado em implementações comerciais, você deve dar uma olhada no Nirvana em my-channels .

    O Nirvana é usado intensamente na indústria de Serviços Financeiros para plataformas de negociação de grande latência e distribuição de preços em larga escala.

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

    Os resources de armazenamento em cluster são extremamente avançados e vale a pena dar uma olhada se o HA transparente ou o balanceamento de carga forem importantes para você.

    O Nirvana é gratuito para download para fins de desenvolvimento.