RocketMQ você deve saber

1. Visão Geral

Escrevi um artigo sobre o Kafka há muito tempo. O que você precisa saber sobre o Kafka. Naquela época, o Kafka era mais usado nos negócios, mas agora, depois de mudar de empresa, o Rocketmq é mais usado. Este artigo Vou tentar o meu melhor para apresentar de forma abrangente a comparação entre os pontos-chave de RocketMQ e Kafka. Espero que todos possam ganhar algo depois de ler.

O antecessor do RocketMQ foi chamado de MetaQ e foi renomeado como RocketMQ quando a versão 3.0 do MetaQ foi lançada. Sua ideia de design essencial é semelhante ao Kafka, mas ao contrário do Kafka, ele usa Java para desenvolvimento, porque o público doméstico de Java é muito mais do que Scala. , Então RocketMQ é a primeira escolha de muitas empresas baseadas na linguagem Java. O mesmo RocketMQ e Kafka são os principais projetos da Apache Foundation. Suas comunidades são muito ativas e as iterações de atualização do projeto também são muito rápidas.

2. Primeiros passos

2.1 Produtor

public class Producer {
    public static void main(String[] args) throws MQClientException, InterruptedException {

        DefaultMQProducer producer = new DefaultMQProducer("ProducerGroupName");
        producer.start();

        for (int i = 0; i < 128; i++)
            try {
                {
                    Message msg = new Message("TopicTest",
                        "TagA",
                        "OrderID188",
                        "Hello world".getBytes(RemotingHelper.DEFAULT_CHARSET));
                    SendResult sendResult = producer.send(msg);
                    System.out.printf("%s%n", sendResult);
                }

            } catch (Exception e) {
                e.printStackTrace();
            }

        producer.shutdown();
    }
}

Defina um produtor diretamente, crie uma Mensagem e chame o método send.

2.2 Consumidor

public class PushConsumer {

    public static void main(String[] args) throws InterruptedException, MQClientException {
        DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("CID_JODIE_1");
        consumer.subscribe("TopicTest", "*");
        consumer.setConsumeFromWhere(ConsumeFromWhere.CONSUME_FROM_FIRST_OFFSET);
        //wrong time format 2017_0422_221800
        consumer.setConsumeTimestamp("20181109221800");
        consumer.registerMessageListener(new MessageListenerConcurrently() {

            @Override
            public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context) {
                System.out.printf("%s Receive New Messages: %s %n", Thread.currentThread().getName(), msgs);
                return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
            }
        });
        consumer.start();
        System.out.printf("Consumer Started.%n");
    }
}

3. Princípio da arquitetura RocketMQ

Para o RocketMQ, primeiro faça algumas perguntas:

• Quais são os tópicos e as filas do RocketMQ e como eles são diferentes das partições Kafka?
• Qual é o modelo de rede RocketMQ e como ele se compara ao Kafka?
• Qual é o modelo de armazenamento de mensagens RocketMQ, como garantir um armazenamento altamente confiável e como ele se compara ao Kafka?

3.1 Diagrama da arquitetura RocketMQ

Para o diagrama de arquitetura do RocketMQ, não há muita diferença do Kafka em geral, mas existem muitas diferenças em muitos detalhes, que serão descritos um a um a seguir.

3.2 Explicação do substantivo RocketMQ

Na arquitetura 3.1, temos vários Produtores, vários Brokers principais e vários Brokers escravos. Cada Produtor pode corresponder a vários Tópicos, e cada Consumidor também pode consumir vários Tópicos.

As informações do corretor serão relatadas ao NameServer, e o consumidor obterá as informações do corretor e do tópico do NameServer.

• Produtor: o produtor da mensagem, o cliente que envia mensagens ao Broker
• Consumidor: consumidor de mensagem, o cliente que lê mensagens do corretor
• Broker: o nó de processamento no meio da mensagem. Isso é diferente de Kafka. O Broker do Kafka não tem o conceito de mestre e escravo. Ele pode gravar solicitações e fazer backup de outros dados do nó. RocketMQ só pode ser gravado pelo nó Broker mestre. Geralmente é lido por meio do nó mestre. A leitura do nó só será usada se houver uma falha ou alguma outra circunstância especial, que é um pouco semelhante - a arquitetura mestre-escravo do mysql.
• Tópico: O assunto da mensagem, o tipo de mensagem de primeiro nível, o produtor envia uma mensagem para ele e o consumidor lê sua mensagem.
• Grupo: Dividido em Grupo de Produtores e Grupo de Consumidores, que representam um determinado tipo de produtores e consumidores. De um modo geral, o mesmo serviço pode ser utilizado como Grupo. De um modo geral, o mesmo grupo envia e consome as mesmas mensagens.
• Tag: esse conceito não existe no Kafka. A tag é um tipo de mensagem secundária. De modo geral, a mesma tag pode ser usada para negócios relacionados, como fila de mensagens de pedido, usando Topic_Order, a tag pode ser dividida em Tag_food pedido, Tag_clothing pedido e muitos mais.
• Fila: é chamada de partição no Kafka. Cada fila é ordenada internamente. No RocketMQ, ela é dividida em dois tipos de filas, leitura e gravação. Em geral, o número de filas de leitura e gravação é o mesmo. Se forem inconsistentes, muitos problemas ocorrerão.
• NameServer: No Kafka, o ZooKeeper é usado para armazenar as informações de endereço do Broker e a eleição do Líder do Broker. No RocketMQ, a estratégia de selecionar o Broker não é adotada, então um NameServer stateless é usado para armazenamento. Como o NameServer é stateless, o cluster Não há comunicação entre os nós, portanto, ao carregar dados, eles precisam ser enviados a todos os nós.

Muitos amigos estão perguntando o que é apátrida? A presença ou ausência de estado é realmente se os dados serão armazenados. Se houver estado, os dados serão persistidos. Um serviço sem estado pode ser entendido como um serviço de memória. O próprio NameServer também é um serviço de memória. Todos os dados são armazenados na memória. Após a reinicialização Será perdido.

3.3 Tópico e Fila

Cada mensagem no RocketMQ tem um tópico para distinguir mensagens diferentes. Um tópico geralmente possui vários assinantes de mensagem.Quando o produtor publica uma mensagem em um tópico, todos os consumidores que assinam este tópico podem receber a nova mensagem escrita pelo produtor.

Existem várias filas no tópico. Esta é realmente a menor unidade para enviar / ler canais de mensagens. Precisamos especificar uma determinada fila ao enviar mensagens. Ao obter mensagens, também precisamos especificar uma determinada recepção Fila, para que nossas mensagens de sequência possam manter a fila em ordem com base em nossa dimensão Fila. Se você quiser atingir a ordem global, é necessário definir o tamanho da fila como 1, para que todos os dados estejam em ordem na Fila.

Na figura acima, nosso produtor selecionará a fila por meio de algumas estratégias:

• Mensagens não sequenciais: as mensagens não sequenciais geralmente são enviadas diretamente por meio do envio round-robin.
• Mensagem de sequência: Hash de acordo com uma determinada chave, como nosso ID de pedido comum e ID de usuário, e coloque o mesmo tipo de dados na mesma fila para garantir nossa sequência.

Nosso mesmo grupo de consumidores também escolherá a Fila de acordo com algumas estratégias, como distribuição igual ou distribuição consistente de Hash.

Deve-se notar que quando o Consumidor fica offline ou online, o rebalanceamento é necessário aqui, isto é, o Rebalanceamento. O mecanismo de rebalanceamento do RocketMQ é o seguinte:

• Obtenha as informações mais recentes do corretor e do tópico regularmente
• Rebalancear a cada 20s
• Selecione aleatoriamente uma Corretora principal do Tópico atual. É importante observar se todas as Corretoras principais serão selecionadas toda vez que você rebalancear, pois haverá uma Corretora e várias Corretoras.
• Obtenha o Broker atual, todas as IDs de máquina do ConsumerGroup atual.
• Em seguida, faça atribuições de políticas.

Como o rebalanceamento é feito regularmente, pode haver uma Fila sendo consumida por dois Consumidores ao mesmo tempo, então haverá entrega de mensagem repetida.

O mecanismo de rebalanceamento de Kafka é diferente do RocketMQ. O rebalanceamento de Kafka é realizado por meio da conexão entre o consumidor e o coordenador. Quando o coordenador detecta a mudança do grupo de consumidores, ele envia um sinal de rebalanceamento durante a pulsação e, em seguida, um ConsumerLeader o reequilibra. Escolha e o coordenador notificará todos os consumidores sobre o resultado.

3.3.1 As leituras e gravações da fila são inconsistentes

A fila no RocketMQ é dividida em dois tipos: leitura e gravação. Quando entrei em contato com a RocketMQ pela primeira vez, sempre pensei que não haveria problemas com a configuração inconsistente do número de filas de leitura e gravação. Por exemplo, quando há muitas máquinas consumidoras, configuramos muitas filas de leitura. No entanto, no processo real, foi descoberto que a mensagem não pôde ser consumida e não houve consumo de mensagem.

• Quando o número de filas de gravação é maior do que o número de filas de leitura, os dados na fila de gravação com IDs maiores que os da fila de leitura não serão consumidos porque não serão alocados aos consumidores.
• Quando o número de filas de leitura é maior que o número de filas de gravação, nenhuma mensagem será entregue a tantas filas.

Este recurso é obviamente inútil no RocketMQ, porque basicamente está configurado para o mesmo tamanho das filas de leitura e gravação.Por que não unificá-lo diretamente, mas é fácil cometer erros de configuração do usuário.

Esta pergunta não recebeu uma boa resposta na edição da RocketMQ.

3.4 Modelo de consumo

De modo geral, existem dois modelos de consumo de filas de mensagens, um modelo push baseado em push e um modelo de mensagem baseado em poll.

Com base no sistema de mensagens do modelo push, o agente de mensagens registra o status de consumo. Depois que o intermediário de mensagem envia a mensagem ao consumidor, ele marca a mensagem como sendo consumida, mas esse método não pode garantir a semântica de processamento do consumo. Por exemplo, quando enviamos uma mensagem ao consumidor, o processo de consumo desliga ou a mensagem não é recebida por motivos de rede.Se marcarmos como consumida no agente de consumo, a mensagem será perdida definitivamente. Se usarmos esse método de resposta após o produtor receber a mensagem, o agente de mensagens precisará registrar o status de consumo, o que não é desejável.

Os alunos que usaram o RocketMQ não podem deixar de pensar que existem dois tipos de consumidores no RocketMQ?
MQPullConsumer e MQPushConsumer, entre os quais MQPushConsumer é o nosso modelo de push? Na verdade, esses dois modelos são o cliente ativamente puxando mensagens, as diferenças de implementação são as seguintes:

• MQPullConsumer: Cada vez que você puxa uma mensagem, você precisa passar o deslocamento da mensagem puxada e quanta mensagem você puxa a cada vez, onde puxar a mensagem e quanto você puxa é controlado pelo cliente.
• MQPushConsumer: O cliente também está ativamente puxando mensagens, mas o progresso da mensagem é salvo pelo servidor, e o consumidor relatará regularmente onde consumiu, para que o consumidor possa encontrar o último ponto de consumo quando consumir na próxima vez. De um modo geral, o PushConsumer é usado Não precisamos nos preocupar com o deslocamento e a quantidade de dados extraída, apenas use-os diretamente.

3.4.1 Consumo de cluster e consumo de transmissão

Temos dois modos de consumo, consumo de cluster e consumo de transmissão:

• Consumo de cluster: O mesmo GroupId pertence a um cluster, geralmente uma mensagem só pode ser processada por qualquer consumidor.
• Consumo de transmissão: a mensagem de consumo de transmissão será enviada por todos os consumidores no cluster, mas deve-se observar que, como o deslocamento do consumo de transmissão é muito caro para economizar no lado do servidor, cada vez que o cliente for reiniciado, ele consumirá as últimas notícias em vez da última vez. O deslocamento salvo.

3.5 Modelo de rede

O soquete nativo usado em Kafka realiza a comunicação de rede, enquanto RocketMQ usa o framework de rede Netty. Agora, mais e mais middleware não escolherá diretamente o soquete nativo, mas usará o framework Netty, principalmente devido ao seguinte Vários motivos:

• A API é simples de usar, não há necessidade de se preocupar com muitos detalhes da rede e mais foco na lógica do middleware.
• Alta performance.
• Maduros e estáveis, os bugs do jdk nio foram corrigidos.

A escolha de um framework é um aspecto, e se você quiser garantir a eficiência da comunicação da rede, o modelo de thread de rede também é um aspecto. Nossos mais comuns são 1 + N (1 thread de aceitação, N threads de IO), 1 + N + M (1 aceitador) Thread, threads N IO, threads de trabalho M) e outros modelos, RocketMQ usa um modelo 1 + N1 + N2 + M, conforme mostrado na figura a seguir:

1 thread de aceitação, thread de E / S N1, threads N2 são usados ​​para aperto de mão, verificação SSL, codificação e decodificação; threads M são usados ​​para processamento de negócios. Este benefício coloca algumas operações potencialmente demoradas, como codificação, decodificação e verificação de SSL em um pool de thread separado, e não ocupará nossos threads de negócios e threads de IO.

3.6 Modelo de armazenamento distribuído altamente confiável

Como um bom sistema de mensagens, armazenamento de alto desempenho e alta disponibilidade são indispensáveis.

3.6.1 Armazenamento de registro de alto desempenho

O design do núcleo de armazenamento do RocketMQ e do Kafka é muito diferente, então também há uma grande diferença no desempenho de gravação. Este é o teste de desempenho realizado pela equipe de middleware Ali no RocketMQ e Kafka sob diferentes tópicos em 16 anos:

Como pode ser visto na figura:

• Quando Kafka aumentou o número de tópicos de 64 para 256, a taxa de transferência caiu 98,37%.
• O rendimento do RocketMQ caiu apenas 16% quando o número de tópicos aumentou de 64 para 256.
  Por que é isso? Todas as mensagens em um tópico no Kafka são distribuídas e armazenadas em vários nós em uma maneira de partição. Ao mesmo tempo, na máquina Kafka, cada partição corresponde, na verdade, a um diretório de log, e há vários segmentos de log no diretório. Portanto, se houver muitos tópicos, Kafka grava arquivos sequencialmente, mas, na verdade, há muitos arquivos, o que causará uma competição de E / S de disco muito acirrada.

Então, por que o RocketMQ ainda mantém mais rendimento, mesmo com vários tópicos? Vejamos primeiro os arquivos principais no RocketMQ:

Existem quatro diretórios aqui (a explicação aqui é o RocketMQ oficial diretamente):

• commitLog: O corpo de armazenamento do corpo da mensagem e metadados, que armazena o conteúdo do corpo da mensagem gravado pelo lado do Produtor, e o conteúdo da mensagem não tem comprimento fixo. O tamanho padrão de um único arquivo é 1G, o comprimento do nome do arquivo é de 20 dígitos, a esquerda é preenchida com zeros e o restante é o deslocamento inicial, por exemplo, 00000000000000000000 representa o primeiro arquivo, o deslocamento inicial é 0 e o tamanho do arquivo é 1G = 1073741824; O primeiro arquivo está cheio, o segundo arquivo é 00000000001073741824, o deslocamento inicial é 1073741824 e assim por diante. As mensagens são principalmente gravadas sequencialmente no arquivo de log. Quando o arquivo está cheio, ele é gravado no próximo arquivo;
• config: Salve algumas informações de configuração, incluindo algumas compensações de consumo de Grupo, Tópico e Consumidor.
• consumeQueue: Fila de consumo de mensagens. O principal objetivo de sua apresentação é melhorar o desempenho do consumo de mensagens. Como RocketMQ é um modelo de assinatura baseado em tópico, o consumo de mensagens é para tópicos. É muito ineficiente percorrer o arquivo commitlog e recuperar mensagens com base no tópico. . O consumidor pode encontrar a mensagem a ser consumida de acordo com ConsumeQueue. Entre eles, ConsumeQueue (fila de consumo lógico) como o índice de mensagens de consumo, salva o deslocamento de deslocamento físico inicial da mensagem da fila no tópico especificado no CommitLog, o tamanho do tamanho da mensagem e o valor HashCode da tag da mensagem. O arquivo consumequeue pode ser considerado um arquivo de índice commitlog baseado em tópico, portanto, a pasta consumequeue é organizada da seguinte forma: estrutura de organização de três camadas de tópico / fila / arquivo, o caminho de armazenamento específico é:
  
  HOME \ store \ index \ $ {fileName}, nome do arquivo fileName é nomeado após o carimbo de data / hora quando foi criado. O tamanho do arquivo IndexFile único fixo é de cerca de 400 M. e um IndexFile pode armazenar índices de 2.000 W. O armazenamento subjacente de IndexFile é projetado para implementar a estrutura HashMap no sistema de arquivos, de modo que o arquivo de índice rocketmq tenha sua camada inferior. Implementado como um índice hash.

Descobrimos que os dados do corpo da nossa mensagem não são gravados em vários arquivos como Kafka, mas em um arquivo, de modo que nossa competição de IO de gravação é muito pequena e ainda podemos manter um alto rendimento quando há muitos tópicos. Alguns alunos disseram que a escrita de ConsumeQueue aqui está constantemente escrevendo, e a ConsumeQueue usa a dimensão Fila para criar arquivos, então a quantidade de arquivos ainda é muito, a quantidade de dados gravada na ConsumeQueue aqui é muito pequena, cada mensagem é apenas 20 Bytes, 30 W de dados equivalem a apenas 6 milhões, então, na verdade, o impacto sobre nós é muito menor do que o impacto entre os tópicos de Kafka. Toda a nossa lógica pode ser a seguinte:

O Produtor adiciona continuamente novas mensagens ao CommitLog. Há uma tarefa cronometrada ReputService que verifica continuamente o CommitLog recém-adicionado e, em seguida, constrói continuamente ConsumerQueue e Index.

Nota: Isso se refere a discos rígidos comuns. A gravação simultânea de vários arquivos e a gravação de um único arquivo no SSD têm pouco efeito.

Leia a mensagem

Cada partição no Kafka será um arquivo separado, portanto, quando uma mensagem for consumida, ela será lida em ordem.Sabemos que quando o sistema operacional ler o arquivo do disco físico, ele lerá sequencialmente outros blocos adjacentes. O arquivo de dados é pré-lido e os dados são colocados no PageCache, portanto, o desempenho de leitura de mensagens do Kafka é melhor.

O processo de leitura do RocketMQ é o seguinte:

• Leia primeiro o deslocamento em ConsumerQueue correspondente ao deslocamento físico de CommitLog
• Leia CommitLog de acordo com o deslocamento

ConsumerQueue também é um arquivo separado para cada Fila e seu tamanho de arquivo é pequeno, portanto, é fácil usar o PageCache para melhorar o desempenho. Quanto ao CommitLog, como as mensagens contínuas da mesma Fila são, na verdade, descontínuas no CommitLog, isso causará leituras aleatórias. RocketMQ fez várias otimizações:

• Leituras de mapeamento Mmap, o método Mmap reduz a sobrecarga de desempenho do IO tradicional copiando dados de arquivo de disco para frente e para trás entre o buffer do espaço de endereço do kernel do sistema operacional e o buffer do espaço de endereço do aplicativo do usuário
• Use o algoritmo de agendamento DeadLine + disco de armazenamento SSD
• Como o mapeamento Mmap é limitado pela memória, quando esta parte dos dados não está mapeada no Mmmap (ou seja, a mensagem é muito acumulada), o padrão é 40% da memória, e a solicitação será enviada ao SLAVE para reduzir a pressão sobre o Mestre

  3.6.2 Disponibilidade

3.6.2.1 Modo de cluster

Primeiro, precisamos escolher um modo de cluster para se adaptar ao grau de usabilidade que podemos suportar. Em geral, existem três tipos:

• Single Master: Neste modo, a disponibilidade é a mais baixa, mas o custo também é o mais baixo, uma vez desligado, tudo fica indisponível. Geralmente, isso se aplica apenas a testes locais.
• Mestre único com vários SLAVE: este modo tem disponibilidade geral. Se o mestre estiver inativo, todas as gravações ficarão indisponíveis e as leituras ainda estarão disponíveis. Se o disco mestre estiver danificado, você pode contar com os dados do escravo.
• Multi-mestre: este modo tem disponibilidade geral. Se parte do mestre estiver inativo, as mensagens nesta parte do mestre não podem ser consumidas e os dados não podem ser gravados. Se uma fila de tópicos estiver em vários mestres, pode ser garantido que não há A parte inferior pode ser consumida e gravada normalmente. Se o disco do mestre estiver danificado, a mensagem será perdida.
• Multi-Master e Multi-Slave: este modo tem a maior disponibilidade, mas o maior custo de manutenção. Quando o master cair, apenas a fila nesta parte do master não será gravável, mas a leitura ainda é possível, e se o master O disco está danificado e pode contar com os dados do escravo.

De modo geral, o quarto tipo será selecionado quando for colocado no ambiente de produção para garantir a maior disponibilidade.

3.6.2.2 Disponibilidade de mensagens

Quando escolhemos o modo de cluster, o que precisamos nos preocupar é como armazenar e copiar esses dados. RocketMQ fornece estratégias síncronas e assíncronas para flashing de mensagem para atender às nossas necessidades. Quando escolhemos flashing síncrono, se FLUSH_DISK_TIMEOUT será retornado após o tempo limite de flashing. Se for um flashing assíncrono, ele não retornará as informações relacionadas ao flashing. Escolher o flashing síncrono pode satisfazer nossa mensagem na medida do possível sem perder.

Além das opções de armazenamento, nossa sincronização mestre-escravo oferece modos síncronos e assíncronos para replicação. Claro, escolher a sincronização pode melhorar a disponibilidade, mas o tempo de RT de envio de mensagens diminuirá em cerca de 10%.

3.6.3 Dleger

Fizemos muitas análises no modo de implantação mestre-escravo acima. Descobrimos que, quando há um problema com o mestre, nossas gravações ficarão indisponíveis, a menos que o mestre seja restaurado ou nosso escravo seja alternado manualmente para o mestre, o que nos leva Na maioria dos casos, o Slave pode apenas ler. RocketMQ lançou Dleger-RocketMQ em versões recentes.Ele usa o protocolo Raft para replicar CommitLog e seleciona automaticamente o mestre, de modo que quando o mestre está desligado, a gravação permanece disponível.

Para obter mais informações sobre Dleger-RocketMQ, você pode ler este artigo: Repositório de commitlog Dledger-RocketMQ baseado no protocolo Raft.

3.7 Mensagem Temporizada / Atrasada

Mensagens programadas e mensagens atrasadas são frequentemente usadas em cenários reais de negócios, como os seguintes:

• Os pedidos são fechados automaticamente se não forem pagos pelas horas extras, porque o estoque é bloqueado depois que o pedido é feito em muitos cenários e precisa ser fechado com o tempo.
• Algumas operações atrasadas são necessárias, como alguma lógica de fundo. Depois de concluir uma determinada lógica, você pode enviar uma mensagem atrasada, como um atraso de meia hora, para realizar a compensação de verificação de fundo.
• Para enviar uma mensagem ao usuário em um determinado momento, também pode ser utilizada uma mensagem atrasada.

Na versão de código aberto do RocketMQ, a mensagem de atraso não suporta nenhum atraso de tempo. Você precisa definir vários níveis de atraso fixos. A configuração padrão atual é: 1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h, de 1s a 2h correspondem aos níveis 1 a 18, e a versão em Alibaba Cloud (com pagamento) pode suportar a qualquer momento (nível milissegundo) em 40 dias. Vejamos primeiro o diagrama esquemático da tarefa de temporização no RocketMQ:

• Etapa 1: o produtor define o nível de atraso necessário na mensagem enviada por ele mesmo.
• Etapa 2: O corretor descobre que esta mensagem é uma mensagem atrasada e substitui o Tópico por um Tópico atrasado.Cada nível de atraso será usado como uma fila separada, armazenando seu próprio Tópico como informação adicional.
• Passo 3: Construir ConsumerQueue
• Passo 4: Tarefas cronometradas examinam o ConsumerQueue de cada nível de atraso regularmente.
• Passo 5: Obtenha o Offset de CommitLog em ConsumerQueue, obtenha a mensagem e julgue se o tempo de execução foi atingido
• Passo 6: Se chegar, restaure o tópico da mensagem e reenvie-o. Se não for alcançado, a execução da tarefa será atrasada pelo período de tempo não atingido.

Pode-se ver que a mensagem atrasada se concretiza criando um Tópico e uma Fila separados.Se quisermos atingir qualquer prazo dentro de 40 dias, com base neste esquema, precisamos de 402460601000 filas, esse custo é muito alto. Então, como é realizado o suporte no Alibaba Cloud a qualquer momento? A suposição aqui é persistir a roda do tempo secundária. A roda do tempo secundária é usada para substituir nosso ConsumeQueue, salvar o Commitlog-Offset e, em seguida, remover continuamente o tempo atual que chegou através da roda do tempo e, em seguida, entregar a mensagem novamente. A lógica de implementação específica requer que um artigo separado seja escrito posteriormente.

3.8 Mensagem de transação

Mensagens de transação também são um recurso importante no RocketMQ, o que pode nos ajudar a completar a consistência final das transações distribuídas. Para transações distribuídas, veja muitos dos meus artigos anteriores com muitas introduções detalhadas. Aqui, preste atenção diretamente à conta oficial. : Latte café.

As etapas específicas para usar mensagens de transação são as seguintes:

• Etapa 1: Chame sendMessageInTransaction para enviar mensagens de transação
• Passo 2: Se a transmissão for bem-sucedida, execute a transação local.
• Passo 3: Se a execução da transação local for bem-sucedida, envie um commit, se falhar, envie um rollback.
• Passo 4: Se um dos estágios, como o envio de commit falhar, o rocketMQ verificará periodicamente do Broker o status da transação local.

Todo o processo de uso da mensagem de transação é mais complicado do que as várias mensagens anteriores. A seguir está o diagrama esquemático da realização da mensagem de transação:

• Passo 1: Envie uma mensagem de transação, também chamada de halfMessage aqui, e substitua Tópico por Tópico de HalfMessage.
• Passo 2: Envie um commit ou rollback. Se for um commit, a mensagem anterior será consultada, então a mensagem será restaurada ao Tópico original e um OpMessage será enviado para registrar que a mensagem atual pode ser excluída. Se for uma reversão, um OpMessage será enviado diretamente para exclusão.
• Passo 3: Há uma tarefa de cronometragem para processar mensagens de transação no Broker. Compare halfMessage e OpMessage regularmente. Se houver OpMessage e o status for delete, a mensagem deve ser confirmada ou rollback, para que esta mensagem possa ser excluída.
• Passo 4: Se a transação expirar (o padrão é 6s) e não houver opMessage ainda, é muito provável que a mensagem de confirmação seja perdida. Aqui, voltaremos e verificaremos o status da transação local de nosso Produtor.
• Passo 5: Execute o Passo 2 de acordo com as informações consultadas.

Descobrimos que RocketMQ implementa mensagens de transação modificando as informações do Tópico original, assim como a mensagem atrasada, e então simula como um consumidor para consumo e faz alguma lógica de negócios especial. Claro, também podemos usar esse método para fazer mais expansão do RocketMQ.

4. Resumo

Aqui, vamos retornar às questões mencionadas no artigo:

• Quais são os tópicos e as filas do RocketMQ e como eles são diferentes das partições Kafka?
• Qual é o modelo de rede RocketMQ e como ele se compara ao Kafka?
• Qual é o modelo de armazenamento de mensagens RocketMQ, como garantir um armazenamento altamente confiável e como ele se compara ao Kafka?

Depois de ler este artigo, você deve ter a resposta em mente. Este artigo fala principalmente sobre a arquitetura de design abrangente do RocketMQ. Se você não leu o suficiente, preste atenção à minha conta oficial.

Se você acha que este artigo é útil para você, sua atenção e encaminhamento são meu maior apoio, O (∩_∩) O: