Este artigo primeiro explica quais problemas o middleware de mensagens geralmente precisa resolver, quais dificuldades serão encontradas para resolver esses problemas, se o Apache RocketMQ pode ser resolvido como um middleware de mensagens distribuídas de alto desempenho e alta taxa de transferência open source pelo Alibaba, e como esses problemas são definidos na especificação. Este artigo apresentará então o design da arquitetura do RocketMQ, para dar aos leitores uma compreensão rápida do RocketMQ.
1. Quais problemas o middleware de mensagens precisa resolver? Publicar/Assinar é a função mais básica do middleware de mensagens e também é relativa à comunicação tradicional de RPC. Não vou entrar em detalhes aqui.
A prioridade descrita na especificação de Prioridade de Mensagem refere-se a uma fila de mensagens, cada mensagem tem uma prioridade diferente, geralmente descrita por inteiros, a mensagem com alta prioridade é entregue primeiro, se a mensagem estiver completamente em uma fila de memória, pode ser ordenada de acordo com a prioridade antes da entrega, de modo que a alta prioridade seja entregue primeiro.
Como todas as mensagens no RocketMQ são persistentes, se forem ordenadas de acordo com a prioridade, a sobrecarga será muito grande, então o RocketMQ não suporta especificamente prioridade de mensagem, mas pode implementar funções semelhantes em uma solução alternativa, ou seja, configurar uma fila com alta prioridade e uma fila com prioridade normal, e enviar diferentes prioridades para diferentes filas.
Para questões prioritárias, elas podem ser resumidas em 2 categorias:
- Desde que a prioridade seja alcançada, ela não é uma prioridade no sentido estrito, e a prioridade geralmente é dividida em níveis alto, médio, baixo ou vários outros níveis. Cada prioridade pode ser representada por um tópico diferente e, ao enviar uma mensagem, especificar tópicos diferentes para representar a prioridade, o que pode resolver a maioria dos problemas de prioridade, mas comprometer a precisão das prioridades de negócios.
- Prioridade estrita, prioridade é expressa como um inteiro, como 0 ~ 65535, esse tipo de problema de prioridade geralmente não é adequado para ser resolvido com tópicos diferentes. Se você quiser que o MQ resolva esse problema, isso terá um impacto muito grande no desempenho do MQ. Aqui está um ponto para garantir que o negócio realmente precisa dessa priorização rigorosa e, se as prioridades forem comprimidas em poucas, qual será o impacto disso no negócio?
Ordem da Mensagem refere-se a um tipo de mensagem que pode ser consumida na ordem em que é enviada. Por exemplo, um pedido gera 3 mensagens, a saber: criação de pedido, pagamento de pedido e conclusão de pedido. Ao consumir, é significativo consumir nessa ordem. Mas, ao mesmo tempo, os pedidos podem ser consumidos em paralelo.
O RocketMQ pode garantir estritamente que as mensagens sejam ordenadas.
Filtro de Mensagens Filtragem de Mensagens Broker
No Broker, filtrar de acordo com as necessidades do consumidor tem a vantagem de reduzir a transmissão de mensagens desnecessárias ao consumidor.
A desvantagem é que isso aumenta o ônus sobre o corretor e é relativamente complexo de implementar.
1. O Taobao Notify suporta uma variedade de métodos de filtragem, incluindo filtragem direta por tipo de mensagem e filtragem flexível de expressões sintáticas, que pode atender quase às necessidades de filtragem mais exigentes.
2. O Taobao RocketMQ suporta filtragem por simples Tag de Mensagem, assim como pelo Cabeçalho e corpo da Mensagem.
3. Filtragem flexível de expressões sintáticas também é suportada na especificação de notificação CORBA.
Filtragem de mensagens do lado do consumidor
Essa filtragem pode ser totalmente personalizada pelo aplicativo, mas o lado negativo é que muitas mensagens inúteis são enviadas ao consumidor.
Existem vários métodos comuns de persistência usados pela persistência de mensagens:
- Persista em um banco de dados, como Mysql.
- Persistir para armazenamento KV, como levelDB, Berkeley DB e outros sistemas de armazenamento KV.
- Persistência na forma de registros de arquivo, como Kafka, RocketMQ
- Crie uma imagem persistente dos dados de memória, como beanstalkd, VisiNotify
- (1), (2) e (3) os três métodos de persistência têm a capacidade de estender o buffer da fila de memória, e (4) são apenas uma imagem de memória, que ainda pode restaurar os dados da memória anterior após o intermediário desligar e reiniciar.
As especificações de notificação JMS e CORBA não especificam explicitamente como persistir, mas o desempenho da parte de persistência determina diretamente o desempenho de todo o middleware da mensagem.
O RocketMQ faz uso total do cache de memória do sistema de arquivos Linux para melhorar o desempenho.
Existem várias situações em que a Fiabilidade das Mensagens afeta a confiabilidade da mensagem:
- O corretor fecha normalmente
- Quebra da corretora
- Travamento do sistema operacional
- A máquina perde energia, mas a fonte de alimentação pode ser restaurada imediatamente.
- A máquina não liga (pode estar danificada em dispositivos chave como CPU, placa-mãe, memória, etc.)
- Dano no dispositivo de disco.
(1), (2), (3) e (4) são todas situações em que recursos de hardware podem ser recuperados imediatamente, e o RocketMQ pode garantir que mensagens não sejam perdidas ou que uma pequena quantidade de dados seja perdida (dependendo se o método de flash é síncrono ou assíncrono).
(5) (6) É um único ponto de falha e não pode ser recuperado; uma vez que ocorre, todas as mensagens desse único ponto são perdidas. Em ambos os casos, o RocketMQ garante que 99% das mensagens não sejam perdidas por replicação assíncrona, mas ainda assim há pouquíssimas mensagens que podem ser perdidas. A tecnologia de escrita dupla síncrona pode evitar completamente pontos únicos, o que inevitavelmente afetará o desempenho, tornando-a adequada para situações com requisitos extremamente altos de confiabilidade de mensagens, como aplicações relacionadas ao dinheiro.
O RocketMQ suporta escrita dupla síncrona a partir da versão 3.0.
Mensagens de baixa latência podem alcançar o consumidor imediatamente após a mensagem chegar ao corretor, sem o acúmulo de mensagens.
O RocketMQ utiliza um método de polling pull longo para garantir que a mensagem seja muito em tempo real, e que a mensagem em tempo real não seja menor que a do push.
Pelo menos uma vez significa que cada mensagem deve ser entregue uma vez.
O RocketMQ Consumer primeiro puxa a mensagem para a área local e depois retorna o ack ao servidor após o consumo.
Exatamente Só uma Vez- A etapa de envio de mensagens não permite enviar mensagens duplicadas.
- Na etapa de Consumir Mensagem, mensagens duplicadas não podem ser consumidas.
Somente quando as duas condições acima forem atendidas a mensagem pode ser considerada "Exatamente Apenas uma Vez", e para alcançar os dois pontos acima, uma enorme sobrecarga inevitavelmente será gerada no ambiente do sistema distribuído. Portanto, para buscar alto desempenho, o RocketMQ não garante esse recurso e exige deduplicação no negócio, o que significa que as mensagens dos consumidores devem ser idempotentes. Embora o RocketMQ não possa garantir estritamente a não duplicação, em circunstâncias normais, raramente há envio e consumo repetidos, apenas anomalias na rede, início e parada do consumidor, e outras situações anormais como duplicação de mensagens.
A razão essencial para esse problema é que há incerteza nas chamadas de rede, ou seja, o terceiro estado de não sucesso nem fracasso, então surge o problema da repetição de mensagens.
O que devo fazer se o Buffer do Corretor estiver cheio? O buffer do broker geralmente se refere ao tamanho do buffer de memória de uma fila no broker, que geralmente é limitado em tamanho, e se o buffer estiver cheio?
Veja como isso é tratado na especificação de Notificação CORBA:
- RejectNewEvents rejeita a nova mensagem e retorna o código de erro RejectNewEvents ao Produtor.
- Descarte mensagens existentes de acordo com uma política específica
- AnyOrder - Qualquer evento pode ser descartado no overflow. Essa é a configuração padrão para essa propriedade.
- FifoOrder - O primeiro evento recebido será o primeiro descartado.
- LifoOrder - O último evento recebido será o primeiro descartado.
- Ordem de Prioridade - Os eventos devem ser descartados em ordem de prioridade, de modo que eventos de menor prioridade sejam descartados antes dos eventos de prioridade maior.
- Prazo de Ordem - Os eventos devem ser descartados primeiro na ordem do prazo de expiração mais curto.
O RocketMQ não possui o conceito de buffer de memória, e as filas do RocketMQ são discos persistentes, e os dados são apagados regularmente.
Para resolver esse problema, o RocketMQ tem uma diferença muito significativa em relação a outros MQs: o buffer de memória do RocketMQ é abstraído em uma fila de comprimento infinito, não importa quantos dados cheguem, ele pode ser instalado, esse infinito é baseado em uma premissa, o broker apaga regularmente dados expirados, por exemplo, o broker salva apenas 3 dias de mensagens, e embora o comprimento desse buffer seja infinito, os dados de 3 dias atrás são excluídos do final da fila.
Consumo retrospectivo refere-se à mensagem de que o consumidor consumiu com sucesso, e a mensagem precisa ser reconsumida devido à demanda do negócio. Por exemplo, devido à falha do sistema consumidor, os dados de 1 hora atrás precisam ser reconsumidos após a recuperação, então o corretor deve fornecer um mecanismo para reverter o progresso do consumo de acordo com a dimensão de tempo.
O RocketMQ suporta consumo retrospectivo baseado no tempo, com uma dimensão temporal precisa a milissegundos, que pode ser retrocedida para frente ou para trás.
A principal função do middleware de empilhamento de mensagens é o desacoplamento assíncrono, e outra função importante é bloquear o pico de inundação de dados do front-end e garantir a estabilidade do sistema back-end, que exige que o middleware de mensagens tenha certa capacidade de empilhamento de mensagens, e o heap de mensagens integra as seguintes duas situações:
- As mensagens são empilhadas em buffers de memória e, uma vez que ultrapassam o buffer de memória, as mensagens podem ser descartadas de acordo com uma determinada política de queda, conforme descrito na especificação de notificação CORBA. É adequado para serviços que toleram descartar mensagens; nesse caso, a capacidade de acumulação das mensagens está principalmente no tamanho do buffer de memória, e a degradação de desempenho não será muito grande após o empilhamento da mensagem, pois a quantidade de dados na memória tem impacto limitado na capacidade de acesso fornecida ao mundo exterior.
- As mensagens são empilhadas em sistemas de armazenamento persistentes como banco de dados, armazenamento KV, formulário de registro de arquivo. Quando as mensagens não podem ser acessadas no cache de memória, é inevitável acessar o disco, o que gerará uma grande quantidade de E/S de leitura, e a taxa de transferência de E/S de leitura determina diretamente a capacidade de acesso das mensagens após o acúmulo.
Existem quatro pontos principais para avaliar a capacidade de acumulação de mensagens:
- Quantas mensagens podem ser empilhadas, quantos bytes? Ou seja, a capacidade de heap da mensagem.
- Depois que uma mensagem é empilhada, a taxa de transferência da mensagem é afetada pelo empilhamento?
- O consumo normal dos consumidores será afetado após o acúmulo de mensagens?
- Depois que as mensagens são empilhadas, qual é o throughput ao acessar mensagens acumuladas no disco?
Transações Distribuídas Várias especificações conhecidas de transações distribuídas, como XA, JTA, etc. Entre elas, a especificação XA é amplamente suportada por grandes fornecedores de bancos de dados, como Oracle, Mysql, etc. Entre eles, o líder de implementação de TM da XA, como o Oracle Tuxedo, é amplamente utilizado em finanças, telecomunicações e outras áreas.
Transações distribuídas envolvem problemas de commit em duas etapas e, em termos de armazenamento de dados, o armazenamento KV deve ser suportado, pois a segunda etapa do rollback de commit precisa modificar o estado da mensagem, o que deve envolver a ação de encontrar a mensagem de acordo com a chave. O RocketMQ evita o problema de encontrar a mensagem de acordo com a chave no segundo estágio, usando o primeiro estágio para enviar a mensagem preparada, obtendo o offset da mensagem, e o segundo estágio para acessar a mensagem pelo deslocamento e modificar o estado, sendo que o offset é o endereço dos dados.
O método de implementação de transações do RocketMQ não é feito por meio do armazenamento KV, mas pelo método de offset, que tem uma falha significativa, ou seja, alterar dados por offset causará muitas páginas sujas no sistema, o que requer atenção especial.
Mensagens agendadas Mensagens agendadas significam que as mensagens não podem ser consumidas pelos consumidores imediatamente após serem enviadas ao corretor, e só podem ser consumidas em um momento específico ou após aguardar um determinado período.
Se você quiser suportar precisão arbitrária em tempos, no nível do intermediário, você deve fazer ordenação de mensagens e, se houver persistência, então a ordenação inevitavelmente gerará uma enorme sobrecarga de desempenho.
O RocketMQ suporta mensagens de temporização, mas não suporta precisão arbitrária no tempo, e suporta níveis específicos, como temporização de 5s, 10s, 1m, etc.
Retentar a Mensagem Após o consumidor falhar em consumir a mensagem, forneça um mecanismo de retentativa para fazer a mensagem consumir novamente. Falhas nas mensagens de consumo do consumidor geralmente podem ser consideradas nas seguintes situações:
- Devido ao motivo da própria mensagem, como falha na desserialização, os dados da mensagem em si não podem ser processados (como recarga da conta telefônica, o número de celular da mensagem atual está desconectado, não pode ser recarregado), etc. Esse erro geralmente exige pular essa mensagem e consumir outras mensagens, e essa mensagem falhada é 99% malsucedida mesmo que o consumo seja tentado novamente imediatamente, então é melhor fornecer um mecanismo de retentativa temporizada, ou seja, tentar novamente após 10 segundos.
- Porque os serviços dependentes de aplicação a jusante estão indisponíveis, como a conexão do banco de dados indisponível, a rede externa do sistema é inacessível, etc. Ao encontrar esse erro, mesmo que a mensagem de falha atual seja pulada, outras mensagens também serão consumidas. Nesse caso, recomenda-se aplicar o sono 30s e consumir a próxima mensagem, o que pode reduzir a pressão sobre o corretor para tentar a mensagem novamente.
Visão geral do RocketMQ Vamos descobrir se o RocketMQ resolve os problemas enfrentados pelo middleware de mensagens mencionado acima.
O que é RocketMQ?
A figura acima é um modelo típico de middleware de mensagens enviando e recebendo mensagens; o RocketMQ também foi projetado dessa forma, resumindo, o RocketMQ possui as seguintes características:
- É um middleware de formato de fila com mensagens de alta performance, alta confiabilidade, alta frequência em tempo real e características distribuídas.
- Produtor, Consumidor e Fila podem ser distribuídos.
- O produtor envia mensagens para algumas filas em turno, a coleção de filas é chamada de Topic, Consumer If broadcast consumption, uma instância consumidora consome todas as filas correspondentes a esse tópico, e se for consumida por cluster, múltiplas instâncias consumidoras consomem a coleção de filas correspondente a esse tópico de forma igual.
- A ordem estrita das mensagens pode ser garantida
- Fornece modos de puxar mensagens ricas
- Capacidades eficientes de escalonamento horizontal de assinantes
- Mecanismo de assinatura de mensagens em tempo real
- Centenas de milhões de mensagens de capacidade de acumulação
- Menor dependência
Estrutura física de implantação do RocketMQ
Como mostrado na figura acima, a estrutura de implantação do RocketMQ possui as seguintes características:
- Servidor de Nomes é um nó praticamente sem estado que pode ser implantado em clusters sem qualquer sincronização de informações entre nós.
- A implantação do Broker é relativamente complexa, Broker é dividido em Master e Slave, um Master pode corresponder a múltiplos Slaves, mas um Slave só pode corresponder a um Master, a correspondência entre Master e Slave é definida especificando o mesmo BrokerName, BrokerIds diferente, BrokerId é 0 para Master e non-0 significa Slave. Os mestres também podem ser utilizados em múltiplos. Cada corretor estabelece uma conexão longa com todos os nós do cluster de Servidores de Nomes e registra informações de tópicos para todos os Servidores de Nomes em intervalos regulares.
- O produtor estabelece uma longa conexão com um dos nós do cluster do Servidor de Nomes (selecionado aleatoriamente), recupera periodicamente informações de roteamento de tópicos do Servidor de Nomes, estabelece uma longa conexão com o mestre que fornece o serviço de tópicos e envia batimentos cardíacos para o mestre em intervalos regulares. O Producer é completamente sem estado e pode ser implantado em clusters.
- O consumidor estabelece uma longa conexão com um dos nós do cluster do Servidor de Nomes (selecionado aleatoriamente), recupera regularmente informações de roteamento de tópicos do Servidor de Nomes e estabelece uma longa conexão com o Mestre e o Escravo que fornecem o serviço de tópico, além de enviar batimentos cardíacos para o Mestre e o Escravo em intervalos regulares. Os consumidores podem assinar mensagens tanto do Mestre quanto do Escravo, e as regras de assinatura são determinadas pela configuração do Corretor.
Estrutura lógica de implantação do RocketMQ
Como mostrado na figura acima, a estrutura lógica de implantação do RocketMQ possui duas características: Produtor e Consumidor.
Usado para representar uma aplicação de mensagens, um Grupo de Produtores contém múltiplas instâncias de Produtor, que podem ser múltiplas máquinas, múltiplos processos de uma máquina ou múltiplos objetos Produtores de um processo. Um Grupo de Produtores pode enviar múltiplas mensagens de Tópico, e o Grupo de Produtores funciona da seguinte forma:
- Identifique um tipo de produtor
- Você pode consultar se existem múltiplas instâncias de Produtor nesse aplicativo de mensagens através da ferramenta de O&M
- Ao enviar uma mensagem de transação distribuída, se o produtor cair inesperadamente, o corretor irá ativamente retornar qualquer máquina do grupo de produtores para confirmar o status da transação.
Usado para representar uma aplicação de mensagens de consumidor, um grupo de consumidores contém múltiplas instâncias de consumidores, que podem ser múltiplas máquinas, múltiplos processos ou múltiplos objetos consumidores de um processo. Múltiplos Consumidores em um Grupo de Consumidores consomem mensagens de forma uniformemente distribuída e, se configurados para difusão, cada instância sob esse Grupo de Consumidores consome a quantidade total de dados.
Estrutura de armazenamento de dados RocketMQ
Como mostrado na figura acima, o RocketMQ adota um método de armazenamento que separa dados de índices. Reduzir efetivamente a perda de recursos de arquivos, recursos de IO e recursos de memória. Mesmo com dados massivos como o Alibaba, cenários de alta concorrência podem reduzir efetivamente a latência de ponta a ponta e possuir fortes capacidades de escalonamento horizontal.
|
Publicado em 28/07/2017 20:26:52
|
|
|
|
Publicado em 29/07/2017 08:09:37