orden de pago

directorio

prefacio

El papel del sistema de pago

procesos básicos

gráfico

flujo código

grupo de subprocesos de procesamiento de base de datos envía un mensaje a MQ, la persistencia

Después del pago con éxito, la distribución de mensajes diagrama de flujo

Las órdenes como el gasto de los consumidores de noticias

prueba

---

---

prefacio

El artículo y las imágenes en un extracto de un artículo no es, por lo detalles no se corresponden en su totalidad. Podemos aprender a desarrollar ideas:

1. Desde el uso del módulo funcional entera;
2. Para procesos centrales;
3. arquitectura del sistema para lograr;
4. A continuación, el flujo de código (secuencia de la figura puede ser empleado).

Los dos primeros puntos son los requisitos de negocio, se realizan las dos funciones.

El papel del sistema de pago

https://www.cnblogs.com/veblen/p/10992167.html

 

procesos básicos

http://www.woshipm.com/pd/1392102.html

orden de pago:

Después de que el usuario pague por su orden, tenemos que conseguir una orden de la información de pago, incluyendo el número de serie del pago, tiempo de pago. Luego completar las órdenes de pago es el envío y otros negocios, pero en el proceso de envío, dependiendo del modelo de negocio de la plataforma, puede estar relacionado con las órdenes de división.

gráfico

https://blog.csdn.net/egworkspace/article/details/78900438?depth_1-utm_source=distribute.pc_relevant.none-task&utm_source=distribute.pc_relevant.none-task

Sigue el número de serie marcado, entonces puede realizar un seguimiento de una solicitud de pago se inicia (diagrama de secuencia en una libre), el proceso se describe como sigue:

1. Presentar una tarea de pago, cuando un cliente necesita para iniciar un pago cuando se inicia es la inclusión de una nueva función de pago a cola de tareas para pagarlo, el proceso se lleva a cabo de forma asíncrona. De acuerdo con el primer argumento presentado por el cliente, la construcción de un nuevo trabajo bien pagado;
2. Ofrecer una tarea, abra una tarea asíncrona que hacer es añadir una nueva tarea a MQ pago, a la espera de ser consumido;
3. Pago descripción de la tarea, una vez que la tarea asíncrona se crea correctamente, el primer paso será construir una buena información del trabajo directamente devolver el pago al cliente;
4. Sondear una tarea, al mismo tiempo, los consumidores pagarán por la nueva encuesta tarea tarea de ejecución del pago abajo;
5. Envía una solicitud de pago, este paso debe basarse en la situación real. No todas las solicitudes de pago tienen que ir a través de plataformas de pago de terceros, tales como Alipay, y para micro-cartas, también necesitan solicitar un parámetro con prepay_id pago, y luego inicia un pago a través del cliente;
6. Respuesta, nada que decir, canales de terceros para volver a pagar los parámetros necesarios;
7. caché resultado, hasta ahora, paga una tarea puede completarse, puede realizar los resultados de la tarea (con o sin éxito) en la memoria caché Redis, el cliente espera para una visita de vuelta en cualquier momento;
8. resultado de la consulta, la tarea cliente después de enviar el pago, después de un cierto intervalo de tiempo (recomendación 2 ~ 3s), iniciar una solicitud a los resultados de las investigaciones;
9. Consulta, Redis directamente en los resultados de la búsqueda;
10. Sincronizar, se trata de una operación asíncrona, pagará tareas resultados de la ejecución "el camino" en sincronía con MongoDB, Redis y los resultados de ejecución de tareas de borrado en la memoria caché. MongoDB principalmente a persistir para la posterior tolerancia a fallos, de reintento, el análisis de datos para proporcionar el aterrizaje de la fuente de datos;
11. A cambio, Redis devuelto por el servidor de la aplicación;
12. el pago de retorno, servidor de aplicaciones y entonces el objeto pago final se devuelven al cliente.

Vayamos un poco más profundo, nos fijamos en tres Diagrama de clases:

Hablemos de la sección de pago ① tarea (PayTask). PayTask Pago y dos están en objeto MongoDB documento, pero durante la ejecución de tareas, PayTask se almacenan en caché con Redis, en cualquier momento conveniente para los iniciados de cliente de Query, se ejecuta con éxito la tarea, el objeto se generan pago, el pago será duradera y PayTask definitiva del MongoDB en. En PayService, hay algunas operaciones básicas para tareas de pago, incluyendo el envío de trabajos, Cancelar, Reintentar, la construcción y así sucesivamente.

② Permítanme decir misión (corredor). Esta parte de RabbitMQ y estrechamente relacionado, paga una vez al formulario de tarea, se pondrá a la cola de ejecución de la tarea, eliminado por el consumidor a realizar. En TaskRunner, hay dos métodos básicos: funcionamiento de la interfaz (tareas), remarcado (tarea), y las tareas se ejecutan tareas de reintento. En AbstractPayTaskRunner buen paquete tiene dos métodos, métodos heredados AbstractPayTaskRunner doTask necesidad de poner en práctica, se puede observar a partir del valor de retorno del proceso es asíncrona. Sobre el mecanismo de reintento, el usuario puede configurar el reintento o no, una vez conjunto TaskInfo.needRetry = true (No es de extrañar, el valor predeterminado es permitir reintentos), se le permitió mecanismo de reintento. Veces (TaskInfo.retryTimes) también pueden proporcionarse reintentos, tres por defecto, cada 1s intervalo, 2S, 3S, tolerancia intervalo de tiempo es un número de columnas 1 aritméticas. Por supuesto, no se permitirá a los usuarios un número ilimitado de reintentos, el sistema ha incorporado un número máximo de reintentos, el número máximo de reintentos construido cinco veces.

¿Por qué cinco?

Se siente, 1s, 2s, 3s, 4s, 5S, toda la cadena de solicitud se estiró hasta los 15s, que el cliente es simplemente un desastre! !

flujo código

Creación de pago

 

grupo de subprocesos de procesamiento de base de datos envía un mensaje a MQ, la persistencia

Después del pago con éxito, la distribución de mensajes diagrama de flujo

Las órdenes como el gasto de los consumidores de noticias

prueba

En el programa de llamadas de prueba sendMessage

Debido a que el envío de un mensaje en el grupo de subprocesos, cuando el programa de prueba (principal) deja de funcionar, el grupo de subprocesos dejará de funcionar, así que para que el programa principal no se detiene al final del método add: System.in.read ();

System.in.read () puede ser implementado de entrada caracteres , caracteres Unicode devueltos, pero el inconveniente es que sólo una entrada de caracteres
System.in.read () devuelve el valor de la ASKII código de entrada (un int entero).