A diferença entre as filas de mensagens RabbitMQ, Kafaka, RocketMQ e Pulsar

1. Introdução

AtivoMQ :

        ActiveMQ é um corretor de mensagens de código aberto desenvolvido pela Apache Software Foundation baseado na linguagem Java e implementa JMS.

CoelhoMQ :

        RabbitMQ é um software corretor de mensagens de código aberto (também conhecido como middleware orientado a mensagens) que implementa o Advanced Message Queuing Protocol (AMQP). O servidor RabbitMQ é escrito na linguagem Erlang, enquanto o clustering e o failover são construídos na estrutura da Open Telecommunications Platform. Todas as principais linguagens de programação possuem bibliotecas clientes que se comunicam com interfaces proxy. RabbitMQ oferece suporte a vários protocolos de mensagens, confirmações de entrega e outros recursos.

Kafka :

        Apache Kafka é um projeto de sistema de mensagens de código aberto desenvolvido pela Apache Software Foundation e escrito em Scala.

        Kafka foi originalmente desenvolvido pelo LinkedIn e de código aberto no início de 2011. Formou-se na Incubadora Apache em outubro de 2012.

        O objetivo deste projeto é fornecer uma plataforma unificada, de alto rendimento e baixa latência para processamento de dados em tempo real. Kafka é um serviço de envio de log distribuído, particionado e com várias réplicas. Ele fornece a funcionalidade de um sistema de mensagens por meio de um design exclusivo.

FogueteMQ :

        Apache RocketMQ é uma plataforma distribuída de mensagens e streaming com baixa latência, forte consistência, alto desempenho e confiabilidade, capacidade terascale e escalabilidade flexível. Ele pega emprestadas ideias de design de Kafka, mas não é uma cópia de Kafka. Implementado com base em JMS.

Pulsar :

        Apache Pulsar é o principal projeto da Apache Software Foundation. É uma plataforma de fluxo de mensagens distribuídas nativa da nuvem de última geração que integra mensagens, armazenamento e computação funcional leve. Ele foi projetado com uma separação entre arquitetura de computação e armazenamento. Ele suporta multilocação, armazenamento persistente e replicação de dados entre regiões em salas de máquinas múltiplas. Possui características de armazenamento de dados de streaming, como forte consistência, alto rendimento, baixa latência e alta escalabilidade. É considerada a mensagem em tempo real. streaming, transmissão e armazenamento na era nativa da nuvem e calcule a solução ideal.

Para uma introdução mais detalhada, leia o documento: " Comparação de filas de mensagens RabbitMQ, RocketMQ, Kafka e Pulsar "

2. Comparação de função e desempenho

• modelo push-pull de consumo

Da forma como os consumidores clientes obtêm mensagens, Kafka e RocketMQ extraem mensagens por meio de pesquisas longas. Pull, RabbitMQ, Pulsar e NSQ usam Push.

A fila de mensagens do tipo pull é mais adequada para cenários de alto rendimento, permitindo que os consumidores controlem seu próprio fluxo e obtenham mensagens com base em suas capacidades reais de consumo. A fila de mensagens do tipo push tem melhor desempenho em tempo real, mas precisa de uma boa estratégia de controle de fluxo (contrapressão).Quando a capacidade de consumo do consumidor é insuficiente, o número de consumo push pode ser reduzido para evitar sobrecarregar o consumidor.

• fila de atraso

Entrega atrasada de mensagens. Quando uma mensagem é gerada e entregue na fila de mensagens, alguns cenários de negócios não desejam que os consumidores recebam a mensagem imediatamente, mas esperem por um período específico de tempo antes que o consumidor possa receber a mensagem para consumo. As filas de atraso são geralmente divididas em dois tipos: atraso baseado em mensagens e atraso baseado em fila. O atraso baseado em mensagens refere-se à definição de um tempo de atraso diferente para cada mensagem. Quando novas mensagens entram na fila, elas são classificadas de acordo com o tempo de atraso. É claro que isso terá um impacto maior no desempenho. Outro tipo de atraso baseado em fila refere-se à configuração de filas com diferentes níveis de atraso. O tempo de atraso de cada mensagem na fila é o mesmo, o que evita a perda de desempenho causada pela classificação baseada no tempo de atraso. Através de uma determinada estratégia de varredura O mensagem expirada pode ser entregue.

Os cenários de uso para mensagens atrasadas incluem novas tentativas de detecção de anomalias, cancelamento de tempo limite de pedido, etc., por exemplo:

• Se a solicitação de serviço for anormal, a solicitação anormal deverá ser colocada em uma fila separada e repetida após 5 minutos;
• O usuário compra mercadorias, mas ainda não pagou. O usuário precisa ser lembrado de pagar regularmente e o pedido será encerrado quando o tempo limite expirar;
• Para uma entrevista ou reunião marcada, envie uma notificação para lembrá-lo novamente meia hora antes do início da entrevista ou reunião.

Kafka não oferece suporte a mensagens atrasadas. Pulsar suporta mensagens atrasadas de segundo nível. Todas as mensagens de entrega atrasadas serão registradas pelo Delayed Message Tracker com o índice correspondente. Quando o consumidor consumir, ele irá primeiro para o Delayed Message Tracker para verificar se há alguma mensagem expirada que precise ser ser entregue. Se houver alguma mensagem expirada, envie uma mensagem, retire o índice correspondente do Tracker, encontre a mensagem correspondente e consuma-a. Se não houver nenhuma mensagem expirada, consuma a mensagem normal diretamente. Para mensagens de atraso de longo prazo, elas serão armazenadas em disco e carregadas na memória quando o intervalo de atraso estiver se aproximando.

As mensagens atrasadas da versão de código aberto RocketMQ são armazenadas temporariamente em um tópico interno, não suportam precisão de tempo arbitrária e suportam níveis específicos, como tempo 5s, 10s, 1m, etc.

RabbitMQ precisa instalar um plug-in Rabbitmq_delayed_message_exchange.

O NSQ salva mensagens atrasadas por meio de uma fila de prioridade na memória, suportando precisão de segundo nível e até 2 horas de atraso.

• fila de letras mortas

Por alguns motivos, a mensagem não pode ser entregue corretamente. Para garantir que a mensagem não será descartada sem motivo, ela geralmente é colocada em uma fila com uma função especial. Essa fila é geralmente chamada de fila de mensagens não entregues. Correspondendo a isso, existe também o conceito de “fila de rollback”, imagine que se ocorrer uma exceção quando o consumidor consumir, então o consumo não será confirmado (Ack), e a mensagem ficará sempre indisponível após a operação de rollback a mensagem será colocada no topo da fila e então continuamente processada e revertida, fazendo com que a fila caia em um loop infinito. Para resolver esse problema, você pode configurar uma fila de reversão para cada fila.Tanto ela quanto a fila de devoluções fornecem um mecanismo de garantia para tratamento de exceções. Em situações reais, a função da fila de reversão pode ser desempenhada pela fila de devoluções e pela fila de novas tentativas.

Kafka não possui fila de devoluções e registra o deslocamento do consumo atual por meio de Offset.

O Pulsar possui um mecanismo de nova tentativa. Quando algumas mensagens são consumidas pelos consumidores pela primeira vez e não recebem uma resposta normal, elas entrarão no tópico de nova tentativa. Quando as novas tentativas atingirem um determinado número de vezes, elas pararão de tentar novamente e serão entregues ao tópico de letras mortas. meio.

RocketMQ usa DLQ para registrar todas as mensagens de falha de consumo.

RabbitMQ implementa uma fila de mensagens mortas em um formato semelhante a uma fila de atraso.

NSQ não tem uma fila de mensagens mortas.

• Fila de prioridade

A fila de prioridade é diferente da fila primeiro a entrar, primeiro a sair. As mensagens com alta prioridade têm o privilégio de serem consumidas primeiro, o que pode fornecer garantias downstream de diferentes níveis de mensagens. Porém, essa prioridade também precisa de uma premissa: se a velocidade de consumo do consumidor for maior que a velocidade do produtor, e não houver acúmulo de mensagens no servidor middleware de mensagens (geralmente chamado simplesmente de Broker), então defina a prioridade para as mensagens enviadas. sem significado substantivo, pois uma mensagem é consumida pelo consumidor assim que o produtor a envia, o que significa que há no máximo uma mensagem no Broker, e a prioridade não tem sentido para uma única mensagem.

Kafka, RocketMQ, Pulsar e NSQ não oferecem suporte a filas prioritárias e a prioridade das mensagens pode ser alcançada por meio de filas diferentes.

RabbitMQ oferece suporte a mensagens prioritárias.

• Rastreamento de mensagem

Geralmente, as mensagens são processadas após a conclusão do consumo e a mensagem não pode mais ser consumida. O retrocesso de mensagens é exatamente o oposto: significa que após o consumo da mensagem, a mensagem consumida anteriormente ainda pode ser consumida. Para mensagens, um problema comum é a "perda de mensagem". Geralmente é difícil rastrear se ela foi realmente perdida devido a defeitos no middleware da mensagem ou devido ao uso indevido pelo usuário. Se o próprio middleware da mensagem tiver uma função de rastreamento de mensagem, você pode reproduzir as mensagens "perdidas" retrocedendo o consumo para descobrir a origem do problema. O papel do retrocesso de mensagens vai muito além disso, como recuperação de índice e reconstrução de cache local.Algumas soluções de compensação de negócios também podem ser implementadas por meio de retrocesso.

Kafka oferece suporte ao retrocesso de mensagens e pode redefinir o deslocamento do consumidor com base no carimbo de data e hora ou no deslocamento especificado para que possa ser consumido repetidamente.

Pulsar suporta retrocesso de mensagens por tempo.

RocketMQ suporta retrocesso no tempo e o princípio de implementação é consistente com Kafka.

RabbitMQ não suporta retrocesso, as mensagens serão marcadas para exclusão uma vez marcadas para confirmação.

As mensagens gerais do NSQ não são rastreáveis, mas você pode usar a ferramenta nsq_to_file para gravar mensagens em um arquivo e, em seguida, reproduzir as mensagens do arquivo.

• Persistência de mensagem

A redução de pico de tráfego é uma função muito importante do middleware de mensagens e, na verdade, essa função se beneficia de sua capacidade de acumulação de mensagens. De certa forma, se um middleware de mensagem não tiver a capacidade de acumular mensagens, então ele não poderá ser considerado um middleware de mensagem qualificado. A acumulação de mensagens é dividida em acumulação de memória e acumulação de disco. De modo geral, a capacidade do disco será muito maior que a capacidade da memória.Para empilhamento do tipo disco, a capacidade de empilhamento é o tamanho de todo o disco. De outra perspectiva, o acúmulo de mensagens também fornece funções de armazenamento redundantes para middleware de mensagens.

Kafka e RocketMQ liberam mensagens diretamente em arquivos de disco para persistência, e todas as mensagens são armazenadas em disco. Contanto que a capacidade do disco seja suficiente, o acúmulo ilimitado de mensagens pode ser alcançado.

RabbitMQ é uma pilha típica na memória, mas não é absoluta. Depois que certas condições são acionadas, haverá uma ação de paginação para paginar as mensagens na memória para o disco (a ação de paginação afetará o rendimento) ou usará diretamente um fila lenta para paginar as mensagens na memória para o disco. As mensagens são persistidas diretamente no disco.

As mensagens Pulsar são armazenadas no cluster de armazenamento BookKeeper e também são arquivos de disco.

NSQ grava mensagens em arquivos por meio da ferramenta nsq_to_file.

• Mecanismo de confirmação de mensagem

A fila de mensagens precisa gerenciar o progresso do consumo e confirmar se o consumidor processa a mensagem com sucesso. O componente da fila de mensagens usando o método push geralmente confirma uma única mensagem. Para mensagens não confirmadas, é realizada uma nova entrega atrasada ou entrada na fila de devoluções. .

Kafka confirma a mensagem através do Offset.

RocketMQ, assim como Kafka, também envia Offset. A diferença é que os consumidores podem marcar mensagens que não foram consumidas como falhas de consumo de mensagens. O Broker tentará novamente a entrega. Se várias falhas de consumo se acumularem, elas serão entregues na fila de mensagens não entregues.

RabbitMQ é semelhante ao NSQ, o consumidor confirma uma única mensagem, caso contrário será colocado novamente na fila para aguardar a próxima entrega.

Pulsar usa gerenciamento especializado de Cursor. A confirmação cumulativa tem o mesmo efeito que Kafka; é fornecida confirmação única ou seletiva.

• TTL da mensagem

Mensagem TTL indica o tempo de sobrevivência de uma mensagem. Se nenhum consumidor consumir a mensagem dentro do tempo TTL após o envio da mensagem, a fila de mensagens excluirá a mensagem ou a colocará na fila de mensagens não entregues.

Kafka exclui mensagens com base no período de retenção definido. É possível que a mensagem não tenha sido consumida e tenha sido excluída após expirar. TTL não é suportado.

Pulsar suporta TTL, caso a mensagem não seja consumida por nenhum consumidor dentro do período TTL configurado, a mensagem será automaticamente marcada como reconhecida. A diferença entre o período de retenção de mensagens e o TTL da mensagem é que o período de retenção de mensagens se aplica a mensagens marcadas como confirmadas e definidas como excluídas, enquanto o TTL se aplica a mensagens que não foram confirmadas. O TTL no Pulsar é ilustrado na legenda acima. Por exemplo, se a assinatura B não tiver consumidores ativos, a mensagem M10 será automaticamente marcada como confirmada após o período TTL configurado ter decorrido, mesmo que nenhum consumidor tenha realmente lido a mensagem.

RocketMQ tem relativamente poucas informações sobre o TTL da mensagem, mas a interface parece suportá-lo.

RabbitMQ possui dois métodos: um é defini-lo nas propriedades da fila ao declarar a fila. As mensagens em toda a fila têm o mesmo período de validade. Você também pode definir atributos para a mensagem ao enviá-la e definir um TTL diferente para cada mensagem.

O NSQ parece ainda não ter suporte e há um problema de solicitação de recurso no estado aberto.

• Isolamento multilocatário

Multilocação refere-se à capacidade de atender vários locatários por meio de uma única instância de software. Um locatário é um grupo de usuários que possuem a mesma “visão” do sistema. Em sistemas que não suportam multilocação, muitas vezes é necessário criar várias instâncias de fila de mensagens para diferentes usuários ou clusters diferentes para obter isolamento físico, o que trará altos custos de operação e manutenção. Como um sistema de mensagens de nível empresarial, os recursos multilocatários do Pulsar são projetados para atender às seguintes necessidades:

• Garanta que SLAs rigorosos possam ser cumpridos sem problemas.
• Garanta o isolamento entre diferentes inquilinos.
• Aplicar cotas na utilização de recursos.
• Fornece segurança por locatário e em nível de sistema.
• Garanta operação e manutenção de baixo custo e gerenciamento o mais simples possível.

Pulsar atende às necessidades acima das seguintes maneiras:

• Obtenha a segurança necessária com autenticação, autorização e ACLs (listas de controle de acesso) para cada locatário.
• Aplique cotas de armazenamento por locatário.

Todos os mecanismos de isolamento são definidos em forma de políticas, que podem ser alteradas durante a operação, reduzindo assim os custos de operação e manutenção e simplificando a gestão.

• sequência de mensagens

A sequencialidade das mensagens refere-se a garantir que as mensagens estejam em ordem. A ordem de consumo da mensagem é consistente com a ordem de produção.

Kafka garante que as mensagens dentro da partição sejam ordenadas.

Pulsar suporta dois modos de consumo: o modo de streaming de assinatura exclusivo garante apenas a ordem das mensagens, e o modelo de fila de assinatura compartilhada não garante a ordem.

RocketMQ precisa usar bloqueios para garantir que uma fila tenha apenas um thread consumidor consumindo ao mesmo tempo para garantir a ordem das mensagens.

RabbitMQ possui condições sequenciais estritas, exigindo envio e consumo de thread único, e não usa funções avançadas, como filas de atraso e filas de prioridade.

NSQ usa o próprio case/select do golang para implementar a distribuição de mensagens.Ele não fornece garantias de pedido, não pode combinar mensagens características com os consumidores e não pode obter o pedido de mensagens.

• Consulta de mensagem

No desenvolvimento real, muitas vezes é necessário verificar o conteúdo das mensagens no MQ, como consultar as mensagens específicas do MQ por meio de um determinado MessageKey/ID. Ou você pode rastrear o link da mensagem para saber de onde ela vem e para onde foi enviada, para que possa solucionar e localizar o problema rapidamente.

A camada de armazenamento Kafka é implementada na forma de um log de confirmação distribuído e cada operação de gravação é anexada sequencialmente ao final do log. A leitura também é uma leitura sequencial. A função de pesquisa não é suportada.

Pulsar pode consultar o conteúdo da mensagem, os parâmetros da mensagem e a trajetória da mensagem de uma mensagem específica por meio do ID da mensagem.

RocketMQ oferece suporte à consulta de mensagens por chave de mensagem, chave exclusiva e ID de mensagem.

RabbitMQ usa um sistema de armazenamento baseado em índice. Eles salvam os dados em uma estrutura de árvore para fornecer o acesso rápido necessário para confirmar mensagens individuais. Como as mensagens RabbitMQ serão excluídas após a confirmação, apenas mensagens não confirmadas podem ser consultadas

O próprio NSQ não suporta persistência e recuperação de mensagens, mas você pode usar ferramentas como nsq_to_http para gravar mensagens em um armazenamento que suporte indexação.

• Padrão de consumo

Kafka tem dois modos de consumo, que acabarão por garantir que apenas um consumidor consuma uma partição:

• Método de assinatura: Quando o número de partições de tópico ou o número de consumidores mudar, o rebalanceamento será executado; ao registrar um ouvinte de rebalanceamento, você pode gerenciar manualmente o deslocamento sem registrar um ouvinte, e Kafka irá gerenciá-lo automaticamente.
• Método de atribuição: mapeie manualmente o consumidor para a partição e o Kafka não realizará o rebancamento.

O Pulsar possui os seguintes quatro modos de consumo: o modo exclusivo e o modo de recuperação de desastres são semelhantes ao Kafka. São modelos de fluxo. Cada partição possui apenas um consumo de consumidor, o que pode garantir a ordem das mensagens. O modo de compartilhamento e o modo de compartilhamento de chave são modelos de fila, vários consumidores podem aumentar a velocidade de consumo, mas não podem garantir a ordem.

• Modo exclusivo exclusivo (modo padrão): Uma Assinatura só pode ser associada a um Consumidor. Somente este Consumidor pode receber todas as mensagens do Tópico. Se o Consumidor falhar, o consumo será interrompido.

• Modo de recuperação de desastres (Failover): Quando houver vários consumidores, eles serão classificados na ordem do dicionário e o primeiro consumidor será inicializado como o único consumidor a receber mensagens. Quando o primeiro consumidor se desconecta, todas as mensagens (não confirmadas e subsequentemente recebidas) serão distribuídas para o próximo consumidor na fila.

• Modo Compartilhado (Compartilhado): As mensagens são distribuídas para diferentes consumidores por meio de um mecanismo de pesquisa round robin (que também pode ser customizado), e cada mensagem será distribuída apenas para um consumidor. Quando um consumidor se desconecta, todas as mensagens não confirmadas enviadas a ele serão reprogramadas e distribuídas para outros consumidores sobreviventes.

• Modo de compartilhamento de CHAVE (Key_Shared): Quando houver vários consumidores, as mensagens serão distribuídas de acordo com a chave. Mensagens com a mesma chave serão distribuídas apenas para o mesmo consumidor.

RocketMQ possui dois modos de consumo, modo de transmissão BROADCASTING e modo de cluster CLUSTERING.

O consumo de transmissão refere-se a: uma mensagem é consumida por vários consumidores. Mesmo que esses consumidores pertençam ao mesmo ConsumerGroup, a mensagem será consumida uma vez por cada consumidor no ConsumerGroup. O conceito de ConsumerGroup no consumo de transmissão pode ser considerado sem sentido em termos de divisão de mensagens.

Modo de consumo de cluster: as instâncias do consumidor em um ConsumerGroup compartilham uniformemente as mensagens consumidas. Por exemplo, um Tópico tem 9 mensagens e um dos ConsumerGroup tem 3 instâncias (talvez 3 processos ou 3 máquinas), então cada instância consome apenas parte delas e as mensagens consumidas não podem ser consumidas por outras instâncias.

O consumo de RabbitMQ e NSQ é semelhante, semelhante ao modo de compartilhamento Pulsar. Na forma de fila, aumentar o número de consumidores em um grupo de consumidores pode aumentar a velocidade de consumo.

• confiabilidade da mensagem

A perda de mensagens é um problema comum que você enfrenta ao usar o middleware de mensagens. Por trás disso, a confiabilidade da mensagem também é um fator chave na medição da qualidade do middleware de mensagens. Especialmente no domínio dos pagamentos financeiros, a fiabilidade das mensagens é particularmente importante. Por exemplo, quando um serviço falha, algumas mensagens que foram produzidas com sucesso pelo produtor serão perdidas durante a comutação de alta disponibilidade? A liberação síncrona é uma maneira eficaz de aumentar a confiabilidade de um componente, e o middleware de mensagens não é exceção. Tanto o Kafka quanto o RabbitMQ podem suportar a liberação síncrona, mas na maioria dos casos, a confiabilidade de um componente não deve ser determinada pela liberação síncrona. Em vez de usando operações que consomem extremamente desempenho para garanti-lo, um mecanismo de múltiplas cópias é usado para garanti-lo.

Kafka pode definir o nível de confiabilidade configurando o parâmetro request.required.acks, que indica quantas cópias de uma mensagem precisam confirmar o recebimento bem-sucedido antes de ser enviada com sucesso pela tarefa.

• request.required.acks=-1 (confirmação síncrona completa, forte garantia de confiabilidade)
• request.required.acks=1 (líder confirma recebimento, padrão)
• request.required.acks=0 (sem confirmação, mas alto rendimento)

Pulsar tem um conceito semelhante ao Kafka, chamado Ack Quorum Size (Qa). Qa é o número de Bookies que precisam ser confirmados por uma resposta após o envio de cada solicitação de gravação. Quanto maior o valor, mais tempo leva para confirmar que o a gravação foi bem-sucedida. Seu valor O limite superior é o número de cópias Qw. Para consistência, Qa deve ser (Qw+1)/2 ou mais, ou seja, para garantir a segurança dos dados, o limite inferior de Qa é (Qw+1)/2.

RocketMQ é semelhante ao Kafka.

RabbitMQ é uma arquitetura mestre-escravo que implementa múltiplas cópias e semântica de forte consistência por meio de filas em anel espelhadas. Múltiplas cópias podem garantir que, após o nó mestre cair de forma anormal, o escravo possa ser promovido como o novo mestre e continuar a fornecer serviços para garantir a disponibilidade.

O NSQ armazenará mensagens em arquivos locais através do componente go-diskqueue,e controlará o tamanho da fila na memória através do parâmetro mem-queue-size.Se mem-queue-size=0,cada mensagem será armazenada no disco,e lá não há necessidade de se preocupar com reinicializações de nós, resultando em perda de mensagens. Porém, por estar armazenado no disco local, se o nó ficar offline, as mensagens acumuladas no disco do nó serão perdidas.