Modelo de processamento assíncrono
Quando se trata de distribuído, microsserviços e outros pronomes altamente atraentes, você sempre pode se destacar na entrevista, não porque a tradução para o inglês dessas palavras seja boa, mas a Internet moderna e até mesmo o desenvolvimento de nível empresarial são realmente distribuídos. Bons efeitos de arquitetura foram alcançados com os microsserviços e outros modos. Quer se trate de microsserviços ou da SOA anterior, é sempre indissociável do modelo de processamento assíncrono, desde o processamento de IO no programa à troca de mensagens entre sistemas, existem números assíncronos por todo o lado.
Quando se trata de processamento assíncrono de mensagens entre sistemas, é preciso falar sobre filas de mensagens (MQ). No momento, os tipos de MQ mais populares na indústria, faça seu próprio suplemento cerebral Baidu. Mas preciso lembrar que o MQ é apenas uma solução para atingir o processamento de dados assíncrono. O processamento assíncrono pode ser alcançado sem o MQ? Obviamente, a maneira mais simples e rude é usar o método do banco de dados.O produtor da mensagem insere diretamente os dados no banco de dados e o consumidor usa o método de leitura do banco de dados para obter os dados, portanto MQ não significa processamento assíncrono.
O processamento de mensagens assíncronas desacopla cada sistema ao máximo e oferece mais espaço para expansão independente de cada sistema. No entanto, o processamento de mensagens assíncronas também enfrenta alguns desafios, como: desempenho do pipeline de mensagens e alta disponibilidade de pipelines de mensagens, entre os quais a maioria Perto da camada de negócios pode não haver "tratamento de exceção de dados". Basicamente, esse é o fim do modelo de processamento de dados, o fim do fluxo de dados, mas geralmente é uma parte mais importante do negócio.
Se uma mensagem assíncrona for usada como parte de uma transação distribuída, o feedback do resultado do processamento da mensagem também é projetado e o coordenador distribuído determinará o resultado da transação de acordo com o sucesso do resultado da mensagem.
No que diz respeito ao consumidor de mensagem assíncrona, existem as seguintes soluções de tratamento de exceção de acordo com diferentes cenários de negócios
Ignorar
Esta é a mais crua e simples de todas as soluções de processamento de dados de exceção: quando ocorrer uma exceção, simplesmente ignore e não faça nada.
Não tome nenhuma medida em face de anomalias, isso pode parecer uma solução muito ruim à primeira vista, mas no negócio real, isso pode ser completamente aceitável. Se a perda causada pelo erro for pequena ou mesmo desprezível, o custo de estabelecer um conjunto de mecanismo de correção de erro é muito maior do que ignorar a exceção.Neste cenário, optar por ignorá-la muitas vezes é a melhor solução. E quando o mecanismo de correção de erros é projetado para exigir intervenção manual, o custo será maior, e também introduzirá a possibilidade de afetar outros negócios. O que é ainda mais assustador é que se houver um problema com o próprio mecanismo de correção de erros, o custo será ainda mais ... .
Pegue um exemplo muito simples: como algumas operações estatísticas em logs de login, se houver uma anormalidade nos dados processados por uma determinada pessoa, ela frequentemente escolherá ignorá-la. Como o próprio negócio estatístico tem um mecanismo de tolerância a falhas de dados, não há diferença entre 100.000 e 100001 em termos de requisitos estatísticos.
Tentar novamente
Quando a solução diretamente ignorada não for viável, pode ser necessário repetir a operação. Se houver uma taxa de sucesso alta o suficiente no caso de tentar novamente, tentar novamente é uma escolha razoável. Embora a nova tentativa possa corrigir erros indiretos, ela não pode fazer nada sobre os dados que violam as regras de negócios e modelos de dados.
No caso mais ideal, se a operação de repetição for idempotente, o que é desempenho idempotente (vá para o Baidu você mesmo)? As coisas serão muito mais simples e as operações de repetição podem ser implementadas com confiança. No entanto, se a operação de nova tentativa não foi bem-sucedida após um período de tempo ou um certo número de vezes, na maioria dos casos, uma certa estratégia de acompanhamento pode ser necessária, como: se ainda falhar após tentar novamente 10 vezes, desista.
Maquiagem
Essa estratégia é frequentemente usada em transações distribuídas, não tanto compensação, mas uma operação de rollback. Principalmente no cenário em que o programa recebe dados e terá uma série de operações, a operação de compensação é semelhante ao conceito de rollback da transação, permitindo que o sistema volte ao estado anterior à série de operações. Este mecanismo de compensação é muito adequado para cenários com requisitos de "transação".
Quais são os cenários de demanda de "transação" em seu negócio? Bem-vindo a refletir na mensagem, e deixe-me mencionar um pouco, a atividade semanal de envio de livros de arquitetura ainda está em andamento, bem-vindo a prestar atenção
Artigos mais interessantes
