Explicação detalhada da prática de repetição da primavera da estrutura de tentativa

A repetição da primavera é uma função de energia independente do lote da mola, que implementa principalmente a tentativa e o fusível. Existem restrições de cenário para tentar novamente, e nem todos os cenários são adequados para tentar novamente, como verificação ilegal de parâmetros, operações de gravação etc. (você precisa considerar se a gravação é idempotente) não é adequada para tentar novamente. O tempo limite de chamada remota ou a interrupção da rede podem ser tentados. Na estrutura de governança de microsserviço, geralmente possui sua própria configuração de tentativa e tempo limite. Por exemplo, o dubbo pode definir tentativas = 1, tempo limite = 500 falha na chamada e tente novamente uma vez, e a chamada falha se não retornar após mais de 500ms. Na Spring Remof, você pode especificar o tipo de exceção que precisa ser repetido e definir o intervalo para cada tentativa e se a tentativa falhar, continue novamente novamente.

Design e implementação

RetryOperations definem a API de tentativa. RetryTemplate é a implementação do modo de modelo da API, que implementa a tentativa e a quebra do circuito. A API fornecida é a seguinte:

 Abertura da interface pública {<t, e estende o throwable> t Execute (RETRYCALLBACK <t, e> retrycallback) lança e; } // Outras APIs foram omitidas

RetryCallback define a operação que precisa ser executada. Depois de definir a operação, é a questão de como tentar novamente. RetryTemplate executa a lógica de como tentar novamente, formulando diferentes estratégias de repetição. A estratégia de tentativa padrão é SimpleRetryPlicy , o que significa que será repetido 3 vezes. Se a tentativa for bem -sucedida, você não continuará tentando novamente. E daí se a tentativa de 3 pés falhou? O processo termina ou retorna o resultado de baixo para cima. Para retornar o resultado de baixo para cima, você precisa configurar RecoveyCallBack . A partir do nome, você pode ver que esta é uma interface de retorno de chamada de baixo para cima, que é a lógica da execução depois que a tentativa falhou. Além do SimpleRetryPolicy , existem outras estratégias de repetição. Vamos dar uma olhada na interface RetryPolicy :

 interface pública Retypolicy estende serializável {boolean canRretry (contexto de rerycontext); ReryContext aberto (pai -rerycontext); Void Close (contexto de rerycontext); Void Registertrowable (contexto de rerycontext, arremesso de arremesso);}

canRetry é chamado toda vez que você tentar novamente. A condição de julgamento de se você pode continuar tentando novamente
Chamado Antes do início da repetição open , um contexto de nova tentativa será criado para RetryContext , e a pilha de nova tentativa será salva.
registerThrowable é chamado toda vez que a exceção é repetida (há uma exceção e continuará a tentar novamente)

Tome SimpleRetryPolicy como exemplo. Quando o número de tentismo atingir 3 (padrão 3 vezes), pare de tentar novamente e o número de repetições é salvo no contexto de nova tentativa.

Forneça a seguinte implementação de estratégia de tentativa:

1. NeverRetRyPolicy: Somente Chamada RETRYCALLBACK é permitida uma vez, nenhuma tentativa é permitida
2. Sempre -RetRypolicy: Permita uma tentativa infinita até bem -sucedida. A lógica inadequada neste método levará a um loop morto
3. SimpleretryPolicy: Política de tentativa fixa, o número máximo de tempos de tentativa é 3 vezes por padrão, a política usada pelo RETRYTEMPLATE por padrão
4. TimeoutretryPolicy: Timeout Time Remold Policy, o tempo limite padrão é 1 segundo e a tentativa é permitida dentro do tempo de tempo limite especificado
5. ExceptionClassifierRetRyPolicy: Defina uma estratégia de tentativa para diferentes exceções, semelhante a uma combinação de estratégias de tentativa, a diferença é que apenas novamente a nova tentativa de diferentes exceções.
6. CircuitbreakerretriaPolicy: Política de repetição com função do disjuntor, 3 parâmetros precisam ser definidos opentimeout, resettimeout e delegado
7. CompositeretryPolicy: Existem dois métodos de combinação. Estratégia de tentativa de combinação otimista significa que, desde que exista uma estratégia que permita a tentativa e a estratégia pessimista de repetição de combinação significa que, desde que haja uma estratégia que não permita a tentativa de tentar, mas não importa qual método de combinação, cada estratégia na combinação será executada.

Represente a estratégia de fallback refere -se a se cada tentativa está novamente novamente ou esperar um pouco antes de tentar novamente. Por padrão, você precisa especificar a política de retirada de BackoffRetryPolicy se precisar configurar um período de espera e tentar novamente. BackOffretRypolicy tem a seguinte implementação:

1. Nobackoffpolicy: sem estratégia de algoritmo de retirada, tente imediatamente após cada tentativa
2. FILLBACKOFFPOLICY: Uma política de backup de tempo fixo. Os parâmetros dorminhocos e backoffperiod precisam ser definidos. O dorminhoco especifica a política de espera. O padrão é Thread.Sleep, ou seja, Sleep Thread, Backoffperiod especifica o tempo de sono e o padrão é 1 segundo.
3. UniformRandombackOffOffpolicy: Política de Retorno de Tempo Random, Sleeper, Minbackoffperiod e Maxbackoffperiod, esta política leva um tempo de sono aleatório entre [MinBackoffperiod, Maxbackoffperiod, MinBackOffperiod, default 500 milissegundos, default maxbackperiod 1500 millisecondss
4. ExponencialBackoffOffpolicy: Política de backão exponencial, parâmetros dorminhocos, initialInterval, maxinterval e multiplicador precisam ser definidos. InitialInterval especifica o tempo inicial de sono, padrão 100 milissegundos, o maxinterval especifica o tempo máximo de sono, o padrão de 30 segundos, o multiplicador especifica o multiplicador, ou seja, o próximo tempo de sono é o tempo de sono atual*multiplicador
5. ExponencialRandombackOffOffpolicy: estratégia exponencial aleatória, a introdução do multiplicador aleatório pode realizar um retorno aleatório do multiplicador

Representação com estado ou tentativa apátrida

A chamada tentativa de apátrida refere-se à tentativa de novo, concluída em um contexto de thread. Caso contrário, se a nova tentativa não concluída em um contexto de thread, tente novamente uma tentativa. A forma anterior SimpleRetryPolicy era uma tentativa apátrida porque a tentativa foi concluída em um loop. Então, o que acontece depois disso ou precisa ser repetido em um estado? Geralmente, existem duas situações: reversão da transação e disjuntor.

DataAccessException é excepcional. A tentativa não pode ser realizada, mas se outras exceções forem lançadas, você poderá tentar novamente.

O fusível significa não lidar com a tentativa no loop atual, mas no modo de tentativa global (não no contexto do thread). O disjuntor saltará do loop e as informações da pilha do contexto do thread serão inevitavelmente perdidas. Definitivamente, é necessário salvar essas informações em um "modo global". A implementação atual é colocada em um cache (implementação do mapa). Você pode continuar a tentar novamente depois de obtê -lo do cache na próxima vez.

Início rápido

Use @EnableRetry na classe que precisa executar a tentativa, se proxyTargetClass=true for definido, isso usa o CGLIB Dynamic Proxy:

 @Configuration@enableretry (proxyTargetClass = true) @ComponentPublic Classe RezyExample {}

Represente com base no número máximo de estratégia de tentativas, se a nova tentativa for repetida 3 vezes e a exceção ainda for lançada, a tentativa será interrompida e o retorno de chamada de baixo para cima será executado. Portanto, o resultado da saída final é Integer.MAX_VALUE :

 private void reryexample3 () lança Exceção {RETRYTEMPLATE RETRYTEMPLATE = new RETRYTEMPLATE (); SimpleRetryPolicy SimpleRetryPolicy = new SimpleRetryPolicy (); SimpleRetryPolicy.SetMaxattempts (3); RETRYTEMPLATE.SETRRETRYPOLICY (SimpleRetryPolicy); Inteiro resultado = RETRYTEMPLATE.EXECUTE (novo RETRYCALLBACK <Inteiro, Exception> () {int i = 0; // Representar a operação @Override public integer DowithRetry (RETRYCONTEXT RETRYCONTRYCTEXT) lança exceção {Log.info ("contagem de retidos: {}", RETRYCONTEXT) }, novo recuperyCallback <Teger> () {// Retornete base @Override Public Inteiro Recuperação (RETRYCONTEXT RETRYCONTEXT) lança exceção {Log.info ("Após a nova nova): {}, método de recuperação chamado! log.info ("resultado final: {}", resultado); } private int len (int i) lança exceção {if (i <10) lançar uma nova exceção (i + "le 10"); retornar i; }

A seguir, descreve como usar o modo de política de repetição do disjuntor (CircuitbreakerretriaPolicy). Os três parâmetros a seguir precisam ser definidos:

1. Delegado: Passagem na Retompolicia (cada implementação de retróspólicia tem sua própria implementação de políticas de repetição), é uma estratégia que realmente determina se deve tentar novamente. Quando a tentativa falha, a política do disjuntor é executada
2. OpenTimeout: OpenWindow, configura o horário do tempo limite para o circuito de fusíveis abrir. Quando o OpenTimeout excede o OpenTimeout, o circuito de fusíveis se torna um estado semi-aberto (enquanto uma tentativa for bem-sucedida, o circuito será fechado)
3. RESETTIMEOUT: Tempo limite, configure o tempo de tempo limite para redefinir o recluso de fusíveis

Julgamento de abertura e fechamento do disjuntor:

1. Quando a tentativa falha e o fusível abre a janela de tempo [0, openwindow) é imediatamente fundido
2. Quando a tentativa falha e o tempo limite excede, o circuito de fusíveis fecha novamente
3. Quando o fusível está meio aberto [OpenWindow, Timeout], o contexto é redefinido enquanto a tentativa for bem -sucedida e o disjuntor estiver fechado

O código de teste é o seguinte:

 Modelo de RETRYTEMPLATE = new RETRYTEMPLATE (); CircuitbreakerretriaPolicy Retrypolicy = new CircuitbreakerretriaPolicy (nova SimpleretryPolicy (3)); retrypolicy.setOpEntimeout (5000); retrypolicy.setReretTimeout (20000); template.setRetRyPolicy (Retropolicia); for (int i = 0; i <10; i ++) {//thread.sleep(100); tente {objeto key = "circuito"; boolean isforceRefresh = false; Estado de repetição = new DefaultretyState (chave, isforceRefresh); String result = template.execute (novo RETRYCALLBACK <String, RunTimeException> () {@Override public String DowithRetry (contexto RERYCONTEXT) lança RUNTimeException {Log.info ("RETYT Count: {}", context.getRetRyCount ()); ThrowAltElTime ("timeout"; String Recuperar (contexto de rerinchontext) lança a exceção {return "padrão"; log.info ("Resultado: {}", resultado); } catch (Exceção e) {System.out.println (e); }}

Como isForceRefresh = false é definido, o valor de key = "circuit" (ou seja, rerycontext) será obtido do cache. Portanto, quando a tentativa falha e this.time < this.openWindow RetryContext

Desenvolvimento de anotação

Se a gravação de um RetryTemplate toda vez que você tiver um requisito de tentativa estiver muito inchado, o uso de anotações pode simplificar bastante o desenvolvimento e reduzir o código duplicado. Aqui está uma tentativa da estratégia máxima de tentativa implementada usando anotações:

 @Retryable (value = sqldataexception.class, backoff = @backoff (value = 0l)) public string service3 () lança sqldataException {log.info ("serviço3 aberto"); lançar novas sqldataException (); } @Recover public string recuperar (sqldataException ne) {return "sqldataException recuperado"; }

As anotações incluem:

@Enableretry

@Retryable

@Recuperar

@Backoff

@Circuitbreaker

@Enableretry: você pode tentar novamente? Quando a propriedade ProxyTargetClass é verdadeira (padrão false), use o CGLIB Proxy

@Retryable: o método que a anotação precisa ser tentativa

1. Inclua especifica a classe de exceção a ser processada. O padrão está vazio
2. Exclua especifica exceções que não precisam ser tratadas. O padrão está vazio
3. O VAUE especifica a exceção a tentar novamente. O padrão está vazio
4. Maxattemvens o número máximo de tentativas. Padrão 3 vezes
5. RECOLHE A POLÍTICA DE ESPERANÇA. Use @backoff anotação por padrão

@Backoff: tente novamente a estratégia de fallback (tente agora ou espere um tempo antes de tentar novamente)

1. Quando nenhum parâmetros é definido, o FeltBackOffPolicy é usado por padrão. Represente e aguarde 1000ms.
2. Ao definir apenas a propriedade de atraso (), use FELLBACOFFPOLICY para tentar aguardar o número especificado de milissegundos
3. Ao definir as propriedades de atraso () e maxdealy (), tente novamente e aguarde uma distribuição homogênea entre esses dois valores
4. Use exponencialbackofffpolicy ao usar as propriedades de atraso (), maxdealy () e multiplicador ()
5. Quando a propriedade multiplicier () é definida não igual a 0, e a propriedade Random () também é definida, use exponencialRandombackofffpolicy

@Recover: para uso com métodos. Usado como um método "garantido" quando o @Retryable falha. O método da anotação @Recover deve ser consistente com o método "assinatura" da anotação @retryable. O primeiro parâmetro de entrada é a exceção a ser repetida. Outros parâmetros são consistentes com @retryable. O valor de retorno deve ser o mesmo, caso contrário, não pode ser executado!

@Circuitbreaker: usado para método, implemente o modo de quebra de circuito.

1. Inclua especifica a classe de exceção a ser processada. O padrão está vazio
2. Exclua especifica exceções que não precisam ser tratadas. O padrão está vazio
3. O VAUE especifica a exceção a tentar novamente. O padrão está vazio
4. Maxattemvens o número máximo de tentativas. Padrão 3 vezes
5. OpenTimeout configura o tempo de tempo limite para a abertura do fusível, o padrão 5S. Quando o OpenTimeout excede o OpenTimeout, o circuito de fusíveis se torna um estado semi-aberto (desde que uma tentativa seja bem-sucedida, o circuito será fechado)
6. RESETTIMEOUT Configure o tempo de tempo limite para recarregar o fusível, o padrão de 20 anos, se o disjuntor estiver fechado após esse período

Para mais exemplos, seja bem-vindo ao meu github (https://github.com/happyxiaofan/springboot-learning-example). Obrigado

O exposto acima é todo o conteúdo deste artigo. Espero que seja útil para o aprendizado de todos e espero que todos apoiem mais o wulin.com.