Autor: Longji
consistência
Vejamos primeiro o primeiro recurso do RocketMQ - mensagem de transação.A mensagem de transação é um recurso do RocketMQ relacionado à consistência e também é o recurso mais distintivo do RocketMQ que é diferente de outras filas de mensagens.
Tomando como exemplo um sistema de comércio eletrônico em grande escala, após o pagamento ser bem-sucedido, o banco de dados de pedidos no sistema de transações atualizará o status do pedido para pago. Em seguida, o sistema de negociação envia uma mensagem ao RocketMQ, e o RocketMQ notifica todos os aplicativos downstream sobre o evento de que o pedido foi pago para garantir o cumprimento subsequente do contrato.
No entanto, há um problema no processo acima. O sistema de negociação grava o banco de dados e envia a mensagem separadamente. Não é uma transação e haverá muitas situações anormais. Por exemplo, o banco de dados foi gravado com sucesso, mas a mensagem não foi enviada. O aplicativo downstream não pode receber o status deste pedido. Para e-mails, para negócios comerciais, isso pode fazer com que um grande número de usuários paguem, mas o vendedor não entrega as mercadorias; e se a mensagem for enviada com sucesso primeiro e então, o banco de dados falha ao ser gravado, fará com que o aplicativo downstream pense que o pedido foi pago e promoverá o vendedor a enviar as mercadorias, mas o usuário real não pagou com sucesso. Essas anomalias causarão uma grande quantidade de dados sujos para o negócio de comércio eletrônico e produzirão consequências comerciais catastróficas.
A capacidade de mensagem de transação RocketMQ pode garantir a consistência das transações locais do produtor (como gravação no banco de dados) e transações de mensagens.Finalmente, por meio da semântica de consumo do Broker pelo menos uma vez, pode garantir que as transações locais do consumidor também possam ser executadas com sucesso e, finalmente, realizar a produção. O autor e o consumidor chegam a um acordo final sobre o status da transação do mesmo negócio.
Consistência: Mensagens Transacionais - Princípios
Conforme mostrado na figura abaixo, as mensagens de transação são implementadas principalmente por meio de uma combinação de envio em dois estágios + mecanismo de compensação de transação.
Primeiro, o produtor enviará meia mensagem, que é uma mensagem de preparação, e o corretor salvará metade na fila. Em seguida, o produtor executa uma transação local, geralmente gravando no banco de dados. Após a conclusão da transação local, ele enviará uma operação de commit para o RocketMQ, e o RocketMQ gravará a operação de commit na fila OP, executará a compactação e gravará o mensagem confirmada para o ConsumeQueue para consumidores visíveis. Por outro lado, se for uma operação de rollback, a meia mensagem correspondente será ignorada.
Diante de situações anormais, como a queda do produtor antes de enviar commit ou rollback, o corretor RocketMQ também terá um mecanismo de verificação de compensação para verificar regularmente o status da transação do Produtor e continuar avançando a transação.
Quer se trate de mensagens de preparação, mensagens de confirmação/reversão ou links compactos, no nível de armazenamento, a filosofia de design do RocketMQ de leitura e gravação sequencial é seguida para atingir o rendimento ideal.
Consistência: demonstração de mensagem de transação
A seguir, vejamos um exemplo simples de mensagem de transação. O uso de mensagens de transação requer a implementação de uma consulta para o status da transação, que é a maior diferença em relação às mensagens comuns. Se formos um sistema de negociação, a implementação deste revisor de transação pode consistir em consultar o banco de dados com base no ID do pedido para determinar se o status do pedido foi enviado, como criado com sucesso, pago, reembolsado, etc. O processo de produção de mensagens do corpo principal também é muito diferente. É necessário habilitar transações distribuídas e realizar o envio em duas etapas: primeiro é enviada uma mensagem preparada e depois é executada a transação local. A transação local aqui geralmente é para realizar operações de banco de dados. Então, se a transação local for executada com sucesso, faça o commit como um todo e envie a mensagem previamente preparada. Desta forma, os consumidores podem consumir esta mensagem. Se ocorrer uma exceção na transação local, toda a transação será revertida, a mensagem de preparação anterior também será cancelada e todo o processo será revertido. As mudanças no uso das mensagens de transação são refletidas principalmente no código do produtor. O uso dos consumidores é o mesmo das mensagens comuns, o que não é mostrado na demonstração.
Consistência: cenário de mensagem sequencial + princípio
O segundo recurso avançado do RocketMQ são as mensagens sequenciais, que também é um dos recursos apresentados. Resolve o problema de consistência de sequência e garante que a ordem de produção e consumo de mensagens do mesmo negócio permaneça consistente.
O Alibaba já teve um cenário em que o banco de dados de compradores e vendedores era replicado. Como o banco de dados de pedidos do Alibaba usa tecnologia de sub-banco de dados e subtabela, para diferentes cenários de negócios de compradores e vendedores, ele será dividido em bancos de dados de compradores e vendedores com base no a chave primária do comprador e a chave primária do vendedor. A sincronização dos dois bancos de dados adota o mecanismo de distribuição sequencial Binlog.Ao usar mensagens sequenciais, as alterações do Binlog no banco de dados do comprador são reproduzidas no banco de dados do vendedor em ordem estrita, alcançando assim a consistência do banco de dados de pedidos. Se não houver garantia do pedido, poderão aparecer dados sujos no nível do banco de dados, causando sérios erros de negócios.
O princípio de implementação de mensagens sequenciais é mostrado na figura abaixo e é implementado de forma eficiente, aproveitando ao máximo as características de leitura e escrita sequencial natural do Log.
No modelo de armazenamento Broker, cada Tópico terá um ConsumeQueue fixo, que pode ser entendido como uma partição de tópicos. O produtor adiciona uma chave de negócio à mensagem enviada. Nesse caso, o ID do pedido pode ser usado. Mensagens com o mesmo ID do pedido serão enviadas para a mesma partição de tópico sequencialmente. Cada partição será bloqueada apenas por um consumidor em um determinado momento. O consumidor lê mensagens sequencialmente da mesma partição e as consome em série para obter consistência sequencial.
Consistência: demonstração de mensagem sequencial
A seguir, vejamos uma demonstração simples de mensagens sequenciais. Para mensagens sequenciais, tanto os produtores como os consumidores precisam prestar atenção.
Na fase de produção, primeiro deve ser definido o grupo da mensagem. Cada mensagem pode selecionar um ID comercial como grupo de mensagens, e o ID comercial deve ser o mais discreto e aleatório possível. Como o mesmo ID comercial será atribuído ao mesmo fragmento de armazenamento de dados, a produção e o consumo serão serializados nesse fragmento de dados. Se houver pontos de acesso no ID comercial, isso causará séria distorção de dados e acúmulo de mensagens locais.
Por exemplo, no cenário de transações de comércio eletrônico, é melhor escolher o ID do pedido e o ID do comprador, que são mais discretos. Se você escolher um ID de vendedor, pode haver pontos de acesso e o tráfego de vendedores importantes será muito maior do que o de vendedores comuns.
A fase de consumo também é diferente do envio e recebimento de mensagens convencionais.Existem dois modos principais, nomeadamente o modo de consumo push totalmente gerenciado e o modo de consumidor simples semigerenciado que obtém mensagens ativamente. O RocketMQ SDK garantirá que as mensagens do mesmo grupo entrem serialmente na lógica de consumo de negócios. Deve-se observar que o código de consumo do seu próprio negócio também deve ser executado em série e, em seguida, uma confirmação de consumo bem-sucedido deve ser retornada de forma síncrona. Não coloque mensagens do mesmo grupo em outro conjunto de threads para processamento simultâneo, pois isso destruirá a semântica sequencial.
Negócio complexo
Negócio complexo: cenário de filtragem SQL
O terceiro recurso avançado do RocketMQ é o modo de consumo SQL, que também é necessário apenas para cenários de negócios complexos.
Conforme mostrado na imagem acima, o negócio de comércio eletrônico do Alibaba gira em torno de transações, com centenas de empresas diferentes assinando mensagens de transação. O negócio é basicamente voltado para uma determinada área segmentada e só precisa comercializar algumas novidades do tema. De acordo com o modelo tradicional, geralmente é uma assinatura completa do tópico da transação, e o consumidor pode filtrá-lo localmente, mas isso consumirá muitos recursos de computação e rede, principalmente durante o Double Eleven, e o custo desta solução é inaceitável .
Negócios Complexos: Princípios de Filtragem SQL
Para resolver os problemas acima, RocketMQ fornece modo de consumo SQL. No cenário de transação, cada mensagem de pedido terá atributos de negócios de diferentes dimensões, incluindo ID do vendedor, ID do comprador, categoria, província, preço, status do pedido e outros atributos, e a filtragem SQL permite que os consumidores filtrem através de instruções SQL Consumir mensagens de destino. Por exemplo, se um consumidor quiser apenas ficar atento às mensagens de criação de pedidos dentro de uma determinada faixa de preço, crie uma relação de assinatura Tópico=Trade SQL: status=ordercreate e (Preço entre 50 e 100), a Corretora executará cálculos SQL no servidor e retornar apenas dados válidos aos consumidores.
Para melhorar o desempenho, o Broker também apresenta um módulo de filtro Bloom. Quando a mensagem é gravada e distribuída, o resultado é calculado antecipadamente e o filtro de bitmap é gravado para reduzir E/S inválidas.
De modo geral, sua essência é encaminhar continuamente o link de filtragem, desde a filtragem local no lado do consumidor até a filtragem no lado do servidor no momento da gravação, para atingir o desempenho ideal.
Negócio complexo: demonstração de filtragem SQL
Vejamos um exemplo de assinatura SQL. Atualmente, a filtragem RocketMQ SQL suporta julgamento de atributos não vazios, comparação de tamanho de atributos, filtragem de intervalo de atributos, julgamento de conjunto e cálculo lógico, que pode atender à maioria das necessidades de filtragem.
Na etapa de produção da mensagem, além de definir Tópico e Tag, também podem ser adicionados vários atributos customizados. Por exemplo, neste caso, um atributo de região é definido, indicando que a mensagem é enviada da região de Hangzhou. A assinatura do filtro SQL pode ser realizada com base em atributos customizados durante o consumo. O primeiro caso usa uma expressão de filtro para determinar que o campo da região não está vazio e é igual a Hangzhou antes do consumo. O segundo caso adiciona mais condições.Se esta for uma mensagem de pedido, as condições da região e a faixa de preço também podem ser julgadas ao mesmo tempo para decidir se consumirá. O terceiro caso é o modo de recebimento completo, a expressão é diretamente True, este método de assinatura receberá todas as mensagens de um determinado tópico sem qualquer filtragem.
Negócio Complexo: Cenário de Mensagem Programada + Princípio
O quarto recurso avançado do RocketMQ é o tempo de mensagens.
Os produtores podem especificar que uma mensagem não ficará visível para os consumidores até que um determinado período de tempo tenha passado após seu envio. Existem muitos cenários de negócios que exigem o acionamento de eventos de temporização em grande escala. Por exemplo, cenários típicos de comércio eletrônico têm basicamente a lógica de fechar automaticamente o pedido após 30 minutos da criação do pedido e do não pagamento. Mensagens de temporização podem trazer grande comodidade para o cliente. cenários acima.
As mensagens agendadas do RocketMQ são implementadas com base na roda do tempo (TimerWheel). O objetivo da classificação do tempo é alcançado simulando a rotação do mostrador.
Cada grade no TimerWheel representa a menor escala de tempo, chamada Tick. No RocketMQ, cada Tick dura um segundo e as mensagens ao mesmo tempo serão gravadas na mesma grade. Como várias mensagens podem ser acionadas ao mesmo tempo a cada momento, e o tempo de escrita de cada mensagem é diferente, RocketMQ também introduz a estrutura de dados Timerlog.O Timerlog grava os dados de maneira sequencial, e cada elemento contém o índice físico do mensagem e a mensagem anterior apontando para o mesmo momento formam uma lista lógica vinculada. Cada grade do TimeWheel mantém os ponteiros inicial e final da lista de mensagens naquele momento.
O TimerWheel terá um ponteiro, representando o momento atual, que gira em torno do TimerWheel. O ponto apontado pelo ponteiro representa a expiração do Tick. Todos os conteúdos aparecerão juntos e serão gravados no ConsumeQueue, que fica visível para os consumidores.
Atualmente, o desempenho das mensagens agendadas do RocketMQ excedeu em muito o RabbitMQ e o ActiveMQ.
Alta disponibilidade global
A seguir, vamos falar sobre a solução de tecnologia global de alta disponibilidade da RocketMQ. A arquitetura de alta disponibilidade do RocketMQ refere-se principalmente a múltiplas cópias de dados e alta disponibilidade de serviços dentro do cluster RocketMQ. A alta disponibilidade neste artigo é global e a indústria frequentemente se refere a arquiteturas como recuperação de desastres na mesma cidade, três centros em dois locais e multiatividades em locais diferentes.
Atualmente, as transações Ant Pay e Alibaba adotam um multiativo em uma arquitetura de localização remota.O multiativo em um local remoto tem mais vantagens do que o cold standby, a recuperação de desastres na mesma cidade e os modelos de três centros em dois locais , e pode lidar com desastres em nível de cidade, como terremotos, quedas de energia, etc. Além disso, para alguns problemas causados por operações humanas, como a introdução de novos bugs em uma determinada mudança básica do sistema, resultando na indisponibilidade de todo o nível da sala de computadores, a arquitetura multiativa remota pode cortar diretamente o tráfego para salas de computadores disponíveis , priorizando a garantia da continuidade dos negócios, e realocando questões específicas.
Por outro lado, o multi-ativo remoto também pode alcançar expansão no nível da sala de informática.Os recursos de computação e armazenamento de uma única sala de informática são limitados, enquanto a arquitetura multi-ativa remota pode distribuir o tráfego de negócios proporcionalmente às salas de informática em todo o país. Ao mesmo tempo, a arquitetura multiativa permite que todas as salas de computadores forneçam serviços empresariais em vez de ficarem em estado de espera fria, melhorando significativamente a utilização de recursos. Graças ao estado multiativo, a disponibilidade é mais garantida e a confiança é maior face a cortes de tráfego em cenários extremos.
Em uma arquitetura multiativa remota, RocketMQ é responsável pela capacidade multiativa da infraestrutura. A arquitetura multiativa está dividida em vários módulos:
- Camada de acesso: Através da camada de acesso unificado, as solicitações do usuário são distribuídas para várias salas de computadores de acordo com o ID do serviço. O ID do serviço geralmente pode ser o ID do usuário.
- Camada de aplicação: A camada de aplicação geralmente é sem estado.Quando uma solicitação entra em uma sala de informática, é necessário garantir que todo o link da solicitação seja fechado na unidade, tanto quanto possível, incluindo RPC, acesso ao banco de dados e leitura de mensagens e escrita, o que pode reduzir atrasos de acesso e garantir o desempenho do sistema. Não diminuirá devido à arquitetura multiativa.
- Camada de dados: inclui sistemas com estado, como bancos de dados e filas de mensagens. RocketMQ usa o componente conector para realizar a sincronização em tempo real dos dados da mensagem de acordo com a granularidade do tópico e a sincronização em tempo real do status de consumo de acordo com a granularidade combinada do Consumidor e do Tópico.
- Camada global de gerenciamento e controle: É necessário manter regras globais unificadas, atribuir qual tráfego vai para qual sala de computadores; também é necessário gerenciar a configuração de metadados multiativos, quais aplicativos precisam ser mais ativos e quais tópicos precisam ser mais ativos ; além disso, é necessária coordenação no momento da mudança de fluxo O processo de corte de fluxo de todos os sistemas controla a sequência de corte de fluxo.
Resumir
Este artigo apresenta muitos recursos de alto nível do RocketMQ. O primeiro é o recurso de consistência, que inclui consistência sequencial e consistência de negócios distribuída; RocketMQ tem dois recursos para lidar com negócios complexos e de grande escala, um é a assinatura do filtro SQL, que pode lidar com aquele único negócio supergrande. os consumidores têm necessidades de filtragem; outra são as mensagens agendadas, que também é um cenário comum em muitas transações na Internet. Finalmente, introduz a construção de capacidades de recuperação de desastres de alto nível da RMQ e fornece uma solução remota multiativa.
【Atividade】Leve você para brincar com o RocketMQ e concorra ao "Diretor de Avaliação do RocketMQ"
A fim de obter melhor feedback e sugestões de longo prazo dos desenvolvedores em uso real, unimos forças com a comunidade de desenvolvedores do Alibaba Cloud para lançar a atividade "Procurando por RocketMQ Chief Evaluation Officer", procurando pessoas com experiência técnica prática em mensagens desenvolvedores que estão dispostos a avaliar o produto em profundidade e fazer sugestões valiosas. Esperamos sua participação e ajuda os produtos de mensagens Apache RocketMQ e Alibaba Cloud a continuarem a melhorar sua competitividade.
**Entrada no evento
**
Clique aqui para participar agora:
https://developer.aliyun.com/topic/rocketmq?utm_content=g_1000377381&spm=1000.2115.3001.5954
Você pode conduzir diretamente a avaliação do produto:
https://developer.aliyun.com/mission/review/rocketmqtest?spm=a2c6h.28281744.J_2889796290.5.c66c5bacLDNT46