Cenários de uso da fila de mensagens
O middleware da fila de mensagens é um componente importante em sistemas distribuídos e resolve principalmente problemas como acoplamento de aplicativos, mensagens assíncronas, redução de pico e preenchimento de vale. Obtenha alto desempenho, alta disponibilidade, escalabilidade e, eventualmente, arquitetura consistente.
- Desacoplamento: Vários serviços monitoram e processam a mesma mensagem para evitar múltiplas chamadas RPC.
- Mensagens assíncronas: o editor da mensagem não precisa aguardar o resultado do processamento da mensagem.
- Redução de pico e preenchimento de vale: cenários de grande tráfego e gravação, para resistir ao tráfego para serviços de E/S downstream. É claro que, sob tráfego intenso, outras soluções precisam ser utilizadas.
- Estrutura orientada a mensagens: no barramento de eventos, os serviços orientam os serviços ouvindo mensagens de eventos para concluir as ações correspondentes.
Padrão de enfileiramento de mensagens
Modo ponto a ponto, sem consumo repetido
Vários produtores podem enviar mensagens para a mesma fila de mensagens. Depois que uma mensagem for consumida com sucesso por um produtor de mensagens, a mensagem será removida e outros consumidores não poderão processá-la. Se o consumidor não conseguir processar uma mensagem, a mensagem será consumida novamente.
modelo de publicação/assinatura
O modelo publicar-assinar requer registro e assinatura, e as mensagens correspondentes são consumidas de acordo com o registro. Vários produtores podem escrever mensagens no mesmo tópico e várias mensagens podem ser consumidas pelo mesmo consumidor. As mensagens produzidas por um produtor também podem ser consumidas por vários consumidores, desde que estes tenham subscrito a mensagem.
Referência de seleção
- Ordem das mensagens: se a ordem de consumo das mensagens enviadas para a fila pode ser garantida quando consumidas;
- Dimensionamento: Quando há um problema com o desempenho da fila de mensagens, como consumo muito lento, se ela pode suportar a expansão rapidamente; quando há muitas filas de consumo, o que desperdiça recursos do sistema, se pode suportar a redução.
- Retenção de mensagens: após a mensagem ser consumida com sucesso, se ela continuará retida na fila de mensagens;
- Tolerância a falhas:Quando uma mensagem não é consumida, existe algum mecanismo para garantir que a mensagem será bem-sucedida?Por exemplo, uma mensagem assíncrona de reembolso de terceiros precisa garantir que a mensagem seja consumida antes que o reembolso ao usuário possa ser feito. determinado para ser bem-sucedido, portanto deve ser garantida a precisão do consumo bem-sucedido desta mensagem;
- Confiabilidade da mensagem: Haverá alguma perda de mensagem?Por exemplo, se houver duas mensagens A/B, apenas a mensagem B poderá ser consumida e a mensagem A será perdida;
- Tempo de mensagem: inclui principalmente "tempo de sobrevivência da mensagem" e "mensagem atrasada";
- Taxa de transferência: o número máximo de simultaneidades suportadas;
- Roteamento de mensagens: De acordo com as regras de roteamento, assine apenas mensagens que correspondam às regras de roteamento. Por exemplo, se houver mensagens com regras A/B, os consumidores só poderão assinar mensagens A e as mensagens B não serão consumidas.
Kafka
Kafka é uma plataforma de processamento de fluxo de código aberto desenvolvida pela Apache Software Foundation e escrita em Scala e Java. O objetivo deste projeto é fornecer uma plataforma unificada, de alto rendimento e baixa latência para processamento de dados em tempo real. Sua camada de persistência é essencialmente uma “fila de mensagens de publicação/assinatura em larga escala baseada em uma arquitetura de log de transações distribuída”, tornando-a valiosa como uma infraestrutura de nível empresarial para processamento de dados de streaming. (Wikipédia)
terminologia Básica
Produtor : produtor da mensagem. Normalmente, uma mensagem é enviada para um tópico específico. Normalmente, as mensagens escritas são gravadas em cada partição de maneira seletiva. O produtor também pode gravar mensagens na partição especificada definindo o valor da chave da mensagem. Quanto mais uniformemente os dados gravados nas partições, melhor será o desempenho do Kafka.
Tópico : Tópico é um conceito virtual abstrato. Um cluster pode ter vários tópicos, que servem como identificador de um tipo de mensagem. Um produtor envia mensagens para um tópico e os consumidores obtêm mensagens particionadas assinando o tópico.
Partição : Partição é um conceito físico e um Tópico corresponde a uma ou mais Partições. Novas mensagens serão gravadas na partição de forma anexada e as mensagens na mesma partição serão ordenadas. Kafka alcança redundância e escalabilidade de mensagens por meio de particionamento e suporta leitura e gravação físicas simultâneas, o que melhora muito o rendimento.
Réplicas : uma partição possui várias réplicas. Essas cópias são armazenadas no corretor. Cada corretor armazena centenas ou milhares de cópias de diferentes tópicos e partições. O conteúdo armazenado é dividido em dois tipos: cópia mestre. Cada partição possui uma cópia mestre e todo o conteúdo é gravado e consumido. Tudo passará pela cópia mestre; a cópia seguidora não processa nenhuma solicitação do cliente e apenas sincroniza o conteúdo do mestre para replicação. Se ocorrer uma exceção no mestre, um seguidor logo se tornará o novo mestre.
Consumidor : leitor de mensagens. Os consumidores assinam tópicos e leem mensagens em uma determinada ordem. Kafka garante que cada partição só pode ser usada por um consumidor.
Offset : Offset é um tipo de metadados, que é um número inteiro crescente. Kafka o adiciona à mensagem conforme ela é escrita. Os deslocamentos são exclusivos dentro de uma partição. Durante o processo de consumo, o último deslocamento lido será armazenado no Kafka. O deslocamento não será perdido quando o consumidor fechar. A reinicialização continuará o consumo da última posição.
Corretor : servidor Kafka independente. Um tópico possui N partições e um cluster possui N Brokers. Então cada Broker armazenará uma partição deste tópico. Se um tópico tiver N partições e o cluster tiver (N+M) brokers, então N brokers armazenam uma partição do tópico, e os M brokers restantes não armazenam dados de partição do tópico. Se um tópico tiver N partições e o número de intermediários no cluster for menor que N, um intermediário armazenará uma ou mais partições do tópico. Em ambientes de produção reais, tente evitar esta situação, que pode facilmente levar ao desequilíbrio dos dados do cluster Kafka.
estrutura do sistema
O primeiro tópico tem duas produções: Novas mensagens são gravadas na partição 1 ou na partição 2. Ambas as partições possuem backups no broker1 e no broker2. Após a gravação de novas mensagens, as duas partições seguidoras sincronizarão as alterações das duas partições mestres. O consumidor correspondente obterá mensagens das duas partições mestres com base no deslocamento atual e atualizará o deslocamento. O segundo tópico possui apenas um produtor, que também corresponde a duas partições e é distribuído nos dois brokers do cluster Kafka. Quando novas mensagens são gravadas, as duas partições seguidoras sincronizarão as alterações mestres. Os dois Consumidores obtêm mensagens de diferentes partições master.
vantagem
Alto rendimento, baixa latência : Kafka pode processar centenas de milhares de mensagens por segundo e sua latência é de apenas alguns milissegundos;
Escalabilidade : o cluster Kafka suporta expansão a quente;
Durabilidade e confiabilidade : As mensagens são mantidas no disco local e o backup de dados é suportado para evitar perda de dados;
Tolerância a falhas : permite que falhas de nós no cluster, múltiplas cópias de um dado e algumas máquinas fiquem inativas sem perda de dados;
Alta simultaneidade : suporta milhares de clientes lendo e escrevendo ao mesmo tempo.
deficiência
Ordenação de partições : a ordenação só é garantida dentro da mesma partição e a ordenação global não pode ser alcançada;
Sem mensagens atrasadas : a ordem de consumo está na ordem de escrita e mensagens atrasadas não são suportadas
Consumo repetido : O sistema de consumo está inativo ou reiniciado, fazendo com que a compensação não seja enviada;
Rebalancear : Durante o processo de Rebalanceamento, todas as instâncias de consumo no grupo de consumidores pararão de funcionar e aguardarão a conclusão do processo de Rebalanceamento.
cenas a serem usadas
Coleta de log : um grande número de mensagens de log é gravado primeiro no Kafka, e o serviço de dados armazena os dados consumindo mensagens do Kafka;
Sistema de mensagens : dissociação de produtores e consumidores, armazenamento de mensagens em cache, etc.;
Rastreamento de atividades do usuário : Kafka é frequentemente usado para registrar várias atividades de usuários da web ou usuários de aplicativos, como navegar na web, pesquisar, clicar e outras atividades.Essas informações de atividades são publicadas por vários servidores nos tópicos do Kafka e, em seguida, os consumidores se inscrevem nesses tópicos. tópicos.Pode ser usado para monitoramento e análise em tempo real, e também pode ser salvo no banco de dados;
Indicadores de operação : registram dados de operação e monitoramento, incluindo coleta de dados de diversas aplicações distribuídas e produção de feedback centralizado para diversas operações, como alarmes e relatórios;
Processamento de streaming : como streaming de faísca.
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, e clustering e failover são construídos em cima do Open Estrutura da plataforma de telecomunicações. Todas as principais linguagens de programação possuem bibliotecas de cliente para comunicação com a interface do agente. (Wikipedia)
terminologia Básica
Broker : Recebe entidades de link de cliente e implementa fila de mensagens AMQP e funções de roteamento;
Host Virtual : É um conceito virtual e a menor unidade de controle de permissão. Um Host Virtual contém múltiplas trocas e filas;
Exchange : Recebe mensagens de produtores de mensagens e encaminha mensagens para filas. Ao enviar mensagens, as regras de roteamento são determinadas de acordo com diferentes ExchangeTypes.Os ExchangeTypes comumente usados são: direto, fanout e tópico;
Message Queue : Fila de mensagens, armazenada como mensagens consumidas;
Mensagem : Consiste em Cabeçalho e Corpo. Cabeçalho são vários atributos adicionados pelo produtor, incluindo se a Mensagem é persistida, qual MessageQueue a recebe e a prioridade. Corpo é o conteúdo específico da mensagem;
Vinculação : a vinculação conecta o Exchange e o Message Queue. Quando o servidor estiver em execução, será gerada uma tabela de roteamento, que registra as condições de MessageQueue e o valor BindingKey. Quando o Exchange receber a mensagem, ele analisará o cabeçalho da mensagem para obter o BindingKey e enviará a mensagem para o MessageQueue correspondente com base na tabela de roteamento e no ExchangeType. O modo de correspondência final é determinado por ExchangeType;
Conexão : Conexão TCP entre Broker e cliente;
Canal : canal. O Broker e o cliente não podem enviar mensagens se possuírem apenas uma conexão tcp, devendo ser criado um canal. O protocolo AMQP estipula que os comandos AMQP só podem ser executados através do Canal. Uma conexão pode conter vários canais. A razão pela qual um Canal precisa ser estabelecido é porque cada conexão TCP é preciosa. Se cada cliente e cada thread precisar interagir com o Broker e manter uma conexão TCP, a máquina consumirá recursos. Geralmente é recomendado compartilhar a Conexão. RabbitMQ não recomenda que os threads do cliente compartilhem canais antes. Pelo menos garanta que pequenas mensagens enviadas no mesmo canal sejam atravessadas;
Comando : comando AMQP. O cliente usa Comando para completar a interação com o servidor AMQP.
Information Direct: rota de aprendizado da tecnologia de código-fonte do kernel Linux + tutorial em vídeo do código-fonte do kernel
Learning Express: Código-fonte do kernel Linux Ajuste de memória Sistema de arquivos Gerenciamento de processos Driver de dispositivo/pilha de protocolo de rede
estrutura do sistema
Uma mensagem chega ao Exchange correspondente através do canal. Depois de receber a mensagem, o Exchange analisa o conteúdo do cabeçalho da mensagem, obtém a mensagem BindingKey e encaminha a mensagem para o MessageQueue correspondente com base em Binding e ExchangeType e, finalmente, transmite a mensagem ao cliente através Conexão.
Tipo de troca
Direto: correspondência exata
- Somente quando RoutingKey e BindingKey corresponderem completamente, a fila de mensagens poderá obter a mensagem;
- O Broker fornece um Exchange por padrão. O tipo é Direct e o nome é uma string vazia. Ele está vinculado a todas as Filas (distinguidas aqui pelos nomes das Filas).
Fanout: assinatura, transmissão
- Este modo encaminhará a mensagem para todas as filas de roteamento
Tópico: padrão curinga
- RoutingKey é uma string separada por pontos "." (cada string independente separada por pontos "." é chamada de palavra), como "quick.orange.rabbit". BindingKey é igual a RoutingKey;
- Os dois caracteres especiais "#" e "_" em Bindingkey são usados para correspondência difusa, "#" é usado para corresponder a várias palavras únicas e "_" é usado para corresponder a uma única palavra (incluindo zero).
vantagem
- Baseado no protocolo AMQP: Além do Qpid, o RabbitMQ é o único servidor de mensagens que implementa o padrão AMQP;
- Robusto, estável e fácil de usar;
- Comunidade ativa e documentação completa;
- Suporta mensagens agendadas;
- Autenticação conectável, autorização, suporte para TLS e LDAP;
- Ele oferece suporte à consulta de mensagens com base em identificadores de mensagens e à consulta de mensagens com base no conteúdo da mensagem.
deficiência
- O código-fonte de desenvolvimento de Erlang é difícil de entender, o que não conduz ao desenvolvimento e manutenção secundários;
- As interfaces e protocolos são complexos e os custos de aprendizagem e manutenção são elevados.
Resumir
- Erlang tem vantagens de simultaneidade e melhor desempenho. Embora o código-fonte seja complexo, a comunidade é altamente ativa e pode resolver problemas encontrados durante o desenvolvimento;
- Se o tráfego comercial não for grande, você pode escolher o RabbitMQ, que possui funções relativamente completas.
Pulsar
Apache Pulsar é o principal projeto da Apache Software Foundation. É uma plataforma de fluxo de mensagens distribuídas nativa da nuvem de próxima geração que integra mensagens, armazenamento e computação funcional leve. Ele adota um design de arquitetura de separação de computação e armazenamento e oferece suporte a multilocação , armazenamento persistente, replicação de dados inter-regional de sala de várias máquinas tem características de armazenamento de dados de streaming, como forte consistência, alto rendimento, baixa latência e alta escalabilidade.É considerada a melhor solução para transmissão, armazenamento e computação de streaming de mensagens em tempo real na era nativa da nuvem. Pulsar é um sistema de enfileiramento de mensagens modelo pub-sub (publish-subscribe). (enciclopédia)
terminologia Básica
Propriedade : representa o inquilino. Cada propriedade pode representar uma equipe, uma função e uma linha de produtos. Uma propriedade pode conter vários nameapce. A multilocação é um método de isolamento de recursos que pode melhorar a utilização de recursos;
Namespace : A unidade básica de gerenciamento do Pulsar.Permissões, TTL de mensagens, políticas de retenção, etc. podem ser definidas no nível do namaspace. Todos os tópicos em um namaspace herdam as mesmas configurações. Existem dois tipos de namespaces: namespace local, que só é visível dentro do cluster, e namespace global, que é visível para vários clusters.
Produtor : Produtor de dados, responsável por criar mensagens e entregá-las ao Pulsar;
Consumidor : Consumidor de dados, conectado ao Pulsar para receber mensagens e processá-las adequadamente;
Broker : serviço Stateless Proxy, responsável por operações como recebimento de mensagens, entrega de mensagens e balanceamento de carga do cluster. Ele protege o cliente da complexidade do processo de leitura e gravação do lado do servidor e desempenha um papel importante na garantia da consistência e dos dados dos dados. balanceamento de carga. O corretor não persiste metadados. Pode ser ampliado, mas não pode ser reduzido;
BookKeeper : stateful, responsável pelo armazenamento persistente de mensagens. Quando o cluster for expandido, o Pulsar adicionará BookKeeper e Segment (ou seja, Bookeeper's Ledger).Não há necessidade de realizar o Rebalanceamento durante a expansão como o kafka. O resultado da expansão é que os fragmentos são distribuídos em faixas entre vários Bookies.Fragmentos do mesmo Ledger são distribuídos em vários Bookies, fazendo com que leituras e gravações saltem entre vários Bookies;
ZooKeeper : armazena metadados de Pulsar e BookKeeper, configuração de cluster e outras informações, e é responsável pela coordenação entre clusters, descoberta de serviços, etc.;
Tópico : usado para transmitir mensagens do produtor ao consumidor. Pulsar tem um corretor líder no nível do tópico, que supostamente possui a propriedade do tópico.Todos os R/W para este tópico são concluídos por meio deste corretor. Metadados como o relacionamento de mapeamento entre o Ledger e o Fragmento do Tópico são armazenados no Zookeeper, e o Pulsar Broker precisa rastrear esses relacionamentos em tempo real para processos de leitura e gravação;
Ledger : Segmento, os dados subjacentes do Pulsar são armazenados no BookKeeper na forma de Ledger. É a menor unidade excluída pelo Pulsar;
Fragmento : Cada Ledger consiste em vários Fragmentos.
estrutura do sistema
O diagrama da estrutura acima demonstra as duas situações de expansão de capacidade e failover, respectivamente. Expansão: Devido ao aumento no volume de negócios, um novo Bookie N é adicionado, e os segmentos de dados gravados subsequentemente x e o segmento y são gravados no Bookie recém-adicionado. Para manter um resultado de expansão de capacidade equilibrado, o resultado é mostrado em verde módulo na figura acima. Failover: Se o segmento 4 do Bookie 2 falhar, o Pulasr's Topic selecionará imediatamente o Bookie 1 como o serviço para lidar com a leitura e a gravação.
Broker é um serviço stateless que serve apenas para cálculo de dados e não para armazenamento, portanto o Pulsar pode ser considerado um sistema distribuído baseado em Proxy.
vantagem
- Expansão flexível
- Recuperação perfeita de falhas
- Suporta mensagens atrasadas
- Função de replicação integrada para replicação entre regiões, como recuperação de desastres
- Suporta dois modelos de consumo: stream (modo exclusivo) e fila (modo compartilhado)
FogueteMQ
RocketMQ é uma plataforma distribuída de mensagens e streaming de dados com baixa latência, alto desempenho, alta confiabilidade, capacidade de nível de trilhão e escalabilidade flexível. RocketMQ é o middleware de mensagens distribuídas de terceira geração, de código aberto pelo Alibaba em 2012. (Wikipédia)
terminologia Básica
Tópico : Um Tópico pode ter 0, 1 ou vários produtores enviando mensagens para ele. Um produtor também pode enviar mensagens para diferentes Tópicos ao mesmo tempo. Um tópico também pode ser inscrito por 0, 1 ou vários consumidores;
Tag : um tipo secundário de mensagem, que pode fornecer flexibilidade adicional aos usuários. Uma mensagem não pode ter tag;
Produtor : produtor de mensagem;
Broker : armazena mensagens, uma fila leve com Tópico como latitude; encaminha mensagens, um único nó Broker mantém conexões longas e pulsações com todos os nós NameServer e registra regularmente informações de Tópico no NameServer;
Consumidor : Consumidor de mensagens, responsável por receber e consumir mensagens;
MessageQueue : A unidade física de gerenciamento de mensagens. Um tópico pode ter múltiplas filas. A introdução de filas permite capacidades de expansão horizontal;
NameServer : Responsável pelo gerenciamento dos dados originais, incluindo informações de tópico e roteamento.Não há comunicação entre cada NameServer;
Grupo : Um grupo pode se inscrever em vários tópicos. ProducerGroup e ConsumerGroup são um tipo de produtor e um tipo de consumidor, respectivamente;
Offset : Acesse a unidade de armazenamento através do Offset. Todas as mensagens no RocketMQ são persistentes e a unidade de armazenamento tem comprimento fixo. Offset é um tipo Java Long e, teoricamente, não transbordará em 100 anos, portanto, Message Queue é considerado um dado infinitamente longo e Offset é um subscrito;
Consumidor : suporta dois modos de consumo: PUSH e PULL, e suporta consumo de cluster e consumo de transmissão.
estrutura do sistema
vantagem
Suporta modelos de mensagens de publicação/assinatura (Pub/Sub) e ponto a ponto (P2P):
- Fila sequencial: primeiro a entrar, primeiro a sair (FIFO) confiável e entrega sequencial estrita em uma fila; suporta modos de mensagem pull e push;
- A capacidade de acumular milhões de mensagens em uma única fila;
- Suporta vários protocolos de mensagens, como JMS, MQTT, etc.;
- Arquitetura escalável distribuída;
- Satisfazer a semântica de entrega de mensagens pelo menos uma vez;
- Fornece um Dashboard rico, incluindo configuração, indicadores e monitoramento;
- Os clientes suportados atualmente são java, c++ e golang
deficiência
- A atividade comunitária é média;
- Mensagem atrasada: a versão de código aberto não suporta precisão de tempo arbitrária, apenas níveis específicos.
cenas a serem usadas
- Nasceu para o campo da Internet financeira e cenários que exigem alta confiabilidade.
Autor original: Geek Rebirth
