Este artículo estudia principalmente una explicación detallada de los ejemplos de mecanismo de reintento de programación de Java y ejemplos de código relevante compartido. El editor piensa que es bastante bueno y tiene cierto valor de referencia. Los amigos que lo necesitan pueden referirse a él.
Se debe implementar una función en la aplicación: los datos deben cargarse en el servicio de almacenamiento remoto y se realizan otras operaciones cuando el procesamiento de retorno es exitoso. Esta función no es complicada y se divide en dos pasos: el primer paso es llamar al envoltorio de lógica de servicio de descanso remoto para devolver el resultado de procesamiento al método de procesamiento; El segundo paso es obtener el resultado del primer paso o captar la excepción. Si se produce un error o una excepción, la lógica de carga se volverá a intentar, de lo contrario, la operación lógica continuará.
Según la lógica de carga normal, la lógica de la función se ejecuta juzgando si el resultado de la devolución o la escucha de la decisión de excepción está retumbando. Al mismo tiempo, para resolver la ejecución no válida de reintento inmediato (suponiendo que la excepción sea causada por la inestabilidad de la ejecución externa), la lógica de la función es la reexecución para un cierto tiempo de retraso.
public void Commonretry (map <string, object> dataMap) lanza interruptedException {map <string, object> parammap = maps.newhashmap (); parammap.put ("tableName", "createivetable"); parammap.put ("ds", "20160220"); parammap.put ("dataMap", dataMap); resultado booleano = falso; intente {resultado = uploadtoodps (parammap); if (! resultado) {thread.sleep (1000); cargartoodps (parammap); // intenta una vez}} Catch (Exception e) {Thread.sleep (1000); cargartoodps (parammap); // intenta una vez}}La solución anterior aún puede ser inválida para volver a intentarlo. Para resolver este problema, intente aumentar el recuento de reintentos y el intervalo de intervalo de reintento para lograr la posibilidad de aumentar el reintento válido.
public void Commonretry (map <string, object> dataMap) lanza interruptedException {map <string, object> parammap = maps.newhashmap (); parammap.put ("tableName", "createivetable"); parammap.put ("ds", "20160220"); parammap.put ("dataMap", dataMap); resultado booleano = falso; intente {resultado = uploadtoodps (parammap); if (! resultado) {reuploadtoodps (parammap, 1000l, 10); // retrasar múltiples reintentos}} Catch (excepción e) {reuploadtoodps (parammap, 1000l, 10); // retrasar múltiples reintentos}}Hay un problema con la solución 1 y la solución 2: la lógica normal y la lógica de reintento están fuertemente acopladas. La lógica de reintento se basa mucho en los resultados de ejecución de la lógica normal y los disparadores de reintento pasivo para los resultados esperados de la lógica normal. La causa raíz del reintento a menudo se ve abrumada por la lógica compleja, lo que puede conducir a una comprensión inconsistente de qué problemas resolver las operaciones y el mantenimiento posteriores. El reintento es difícil de garantizar y no es propicio para la operación y el mantenimiento, porque el reintento del diseño se basa en excepciones lógicas normales o vuelve a intentar la causa raíz de la conjetura.
Entonces, ¿hay una solución que pueda usarse para desacoplar la lógica normal y volver a intentar la lógica, y al mismo tiempo, puede darle a Retint Logic una solución estandarizada? La respuesta es: es decir, una herramienta de reintento basada en el patrón de diseño del agente. Intentamos usar la herramienta correspondiente para reconstruir el escenario anterior.
La definición específica del patrón de diseño de comando no se explica. La razón principal es que el patrón de comando puede completar la lógica de operación de la interfaz ejecutando el objeto y, al mismo tiempo, la encapsulación interna de la lógica de reintento no está expuesta a los detalles de implementación. Para la persona que llama, es la ejecución de la lógica normal y logra el objetivo de desacoplar. Consulte la implementación de la función específica. (Estructura del diagrama de clases)
Iretry está de acuerdo en la interfaz de carga y reintento, que implementa que tipo ODPSRETRY encapsula la lógica de carga ODP y encapsula el mecanismo de reintento y la estrategia de reintento al mismo tiempo. Al mismo tiempo, use el método de recuperación para realizar la operación de recuperación al final.
Nuestro llamado LogicClient no necesita prestar atención a Retinty. Implementa la función de la interfaz de la convención a través del recuperador de readryer. Al mismo tiempo, el volver al reintento debe responder y procesar la lógica de reintento. El procesamiento de reintento específico del volver al readryer se entrega a la clase de implementación de interfaz de irry real OdpSretry. Al adoptar el modo de comando, la lógica normal y la lógica de reintento se separan elegantemente, y al mismo tiempo, la lógica normal y la lógica de reintento se separan al desarrollar el papel de los volver a clasificar, por lo que el reintento tiene una mejor escalabilidad.
Spring-Retry es un kit de herramientas de código abierto, actualmente disponible Versión 1.1.2. Release, que personaliza la plantilla de operación de reintento y puede establecer políticas de reintento y políticas de retroceso. Al mismo tiempo, vuelva a intentar la instancia de ejecución para garantizar la seguridad del subproceso. Los ejemplos de operación específicos son los siguientes:
Public void upload (final map <string, object> map) lanza la excepción {// construir una instancia de plantilla de reintento retryTTemplate retryTeMplate = new retryTemplate (); // Establezca la política de reintento, establece principalmente el número de reintentos simpleretrypolicy Policy = new SimpleRetryPolicy (3, colecciones. <Class <? Extends showable>, boolean> singletonmap (excepción.class, true)); // Establecer la Política de operación de reintento de respaldo, establecer principalmente el intervalo de reintento FIXBACKOFFPOLICY FIJATIVE FIRETAFOFFPOLICY = new FixedBackOffPolicy (); fijobackoffpolicy.setbackoffperiod (100); retryrytemplate.setretryPolicy (política); retryTemplate.setBackOffPolicy (fijobackoffpolicy); // retryCallback reí bien la instancia de devolución de llamada para envolver la lógica de lógica normal, la primera ejecución y ejecución de retramado son todas esta lógica final retrycallback <objeto, excepción> retryCallback = new RetryCallBack <object, excepción> () {// retryContext Reinty la convención de contexto de la operación, unificar la dowithryrry de objeto de buzón de resorte System.out.println ("hacer algo"); Excepción e = uploadtoodps (mapa); System.out.println (context.getRetryCount ()); tirar e; // presta especial atención a este punto. La raíz del reintento se devuelve a través de la excepción}}; // Recuperar el proceso de reintento normalmente termina o alcanza el límite superior de reintento. Final RecoveryCallback <Sect> RecoveryCallback = New RecoveryCallback <Sect> () {public Object Recover (RetryContext Context) lanza Exception {System.out.println ("Operación de recuperación"); regresar nulo; }}; Pruebe {// Ejecutar el método Ejecutar por retryTeMplate para iniciar la ejecución lógica de RetryTeMplate.Execute (retryCallback, RecoveryCallback); } catch (Exception e) {E.PrintStackTrace (); }}Después de analizar el código de casos, RitrYTMPLATE asume el papel del ejecutor de reintento. Puede establecer SimpleRetryPolicy (política de reintento, establecer el límite superior de reintento, reintentar la entidad raíz), fixBackOffPolicy (política de respuesta fija, establecer el intervalo de tiempo para reintentar alternativo). RETRYTEMPLATE Ejecuta operaciones a través de la ejecución, y dos instancias de clase, retryCallback y RecoveryCallback, se requieren para preparar dos instancias de clase. El primero corresponde a la instancia de lógica de devolución de llamada de reintento y envuelve operaciones funcionales normales. RecoveryCallback implementa la instancia de operación de recuperación al final de toda la operación de ejecución.
La ejecución de RETRYTMPLATE es SFURADA, y la lógica de implementación usa ThreadLocal para guardar el contexto de ejecución de RETRYContext de cada instancia de ejecución.
Aunque la herramienta Spring-Retry puede implementar con elegancia el reintento, hay dos diseños hostiles: uno es que la entidad de reintento está limitada a la subclase lanzable, lo que indica que el REinty está dirigido a las excepciones funcionales rápidas como la premisa de diseño, pero queremos confiar en una entidad del objeto de datos como la entidad de reintento, pero el marco de la red de primavera se debe emitir a la subclass lanzable. Otro es el objeto de afirmación que retira la causa raíz utiliza la instancia de excepción de excepción de Dowithretry, que no se ajusta al diseño de retorno de afirmaciones internas normales.
El reintento de primavera defiende los métodos de reintento en la anotación. La lógica de reintento se ejecuta sincrónicamente. El "fracaso" del reintento está dirigido a Throwable. Si desea determinar si necesita volver a intentarlo en función de un cierto estado del valor de retorno, es posible que solo pueda juzgar el valor de retorno y luego lanzar explícitamente una excepción.
Abstracción de la primavera para reintentar
"Abstract" es una cualidad necesaria para cada programador. Para mí con calificaciones mediocres, no hay mejor manera de mejorar que imitar y comprender excelentes códigos fuente. Para hacer esto, reescribo su lógica central ... Echemos un vistazo a la abstracción de Spring Retry para "volver a intentarlo".
Spring Reinty Interface.jpg
La herramienta de volver al readryer de guayaba es similar a la retrica de primavera. Envuelve el reintento lógico normal definiendo el papel del volver al readrintor. Sin embargo, el volver al readryer de guayaba tiene una mejor definición de política. Sobre la base de respaldar el número de tiempos de reintento y el control de frecuencia de reintento, puede ser compatible con la definición de fuente de reintento que admite múltiples excepciones o objetos de entidad personalizados, lo que le da a la función de reintento más flexibilidad. El volver al readryer de guayaba también es seguro de hilo. La lógica de llamadas de entrada utiliza el método de llamada de java.util.concurrent.callable. El código de muestra es el siguiente:
public void uploadodps (mapa final <string, object> map) {// retryerBuilder construir un readryer de instancia de retry, puede establecer la fuente de reintento y admitir múltiples fuentes de reintento, puede configurar el número de tiempos de reintento o tiempo de tiempo de espera de reintento, y puede configurar el intervalo de tiempo de espera para el tiempo de espera <Boolean> Retryer = RetryerBuilder. <Boolean> Newbuilder () () Retryer ()) ()) ()) ())) .retryifeXception () .// SET EXCEPCIÓN RETRY FUENTE RETRYIFRESULT (nuevo predicado <Boolean> () {// Establecer Fuente de reintento de segmento personalizado, @Override public Boolean Aplication (estado booleano) {// Nota especial: esta aplicación devuelve verdadero, lo que significa que el reintento debe diferenciarse de la semántica de la operación Logic. Devuelve verdadero;}}) .WithStopStrategy (stopStrategies.stoPafterattempt (5)) // establece 5 veces, y también puede establecer el tiempo de tiempo de espera de reintén. java.util.concurrent.callable <V>, por lo que la ejecución es resultado boolean de hilo shifre = retryer.call (new Callable <Boolean> () {@Override public boolean call () lanza excepción {intent {// nota especial: devolver la declaración falsa no requiere volver a justificar, devolver la declaración verdadera debe continuar retrocediendo retroceder devolver uploodps (map);} Catch (excepción de la excepción) Excepción (e); } Catch (ExecutionException e) {} Catch (RetryException ex) {}}Análisis del principio del código de muestra:
RetryerBuilder es un creador de fábrica que puede personalizar la fuente de reintento y puede admitir múltiples fuentes de reintento, puede configurar el número de tiempos de reintento o el tiempo de espera de reintento, y puede configurar el intervalo de tiempo de espera para crear una instancia de retrander.
La fuente de reintento de RetryerBuilder admite objetos de excepción de excepción y objetos de afirmación personalizados, y se establece a través de Retrenyifexception y Retryifresult, admite múltiples y es compatible al mismo tiempo.
El tiempo de espera y la configuración de límite de reintento de RetryerBuilder se implementan utilizando diferentes clases de políticas, y las características del tiempo de espera pueden admitir modos de intervalo inintervalos y fijos.
El volver al readryer es una instancia del volver al readryer, que ejecuta la lógica de operación a través del método de llamada, y encapsula la operación de origen de reintento.
Elegante volver a intentar la comunidad y el principio
Normal y reintento elegantemente desacoplado, reintento afirmando que las instancias condicionales o las instancias de excepción lógica son los medios para la comunicación entre los dos.
Acuerde los intervalos de reintento, las estrategias de reintento diferencial y el tiempo de tiempo de espera de reintento para garantizar aún más la efectividad del reintento y la estabilidad del proceso de reintento.
Todos usan el patrón de diseño del comando, y las operaciones lógicas correspondientes se completan delegando el objeto de reintento, y la lógica de reintento se implementa internamente.
Las herramientas Spring-Tryer y Guava-Tryer son reintentos a prueba de subprocesos y pueden respaldar la corrección de la lógica de reintento en escenarios comerciales concurrentes.
Escenarios aplicables para volver a clasificar con gracia
Existen escenarios de dependencia inestables en la lógica funcional, y es necesario usar el reintento para obtener el resultado esperado o intentar reexecutar la lógica sin terminar de inmediato. Por ejemplo, acceso a la interfaz remota, acceso de carga de datos, verificación de carga de datos, etc.
Hay escenarios que necesitan volver a intentar los escenarios de excepción, y al mismo tiempo, se espera desacoplar la lógica normal y la lógica de reintento.
Para las interacciones basadas en los medios de datos, los esquemas de reintento también se pueden considerar en escenarios que requieren el reintento de la encuesta para detectar la lógica de ejecución.
Lo anterior es toda la explicación detallada del ejemplo del mecanismo de reintento de reintento de programación Java. Espero que sea útil para todos. Los amigos interesados pueden continuar referiéndose a otros temas relacionados en este sitio. Si hay alguna deficiencia, deje un mensaje para señalarlo. ¡Gracias amigos por su apoyo para este sitio!