prefacio
Después de que el sistema se vuelve compleja, distribuida, servicio y otra tecnología de micro-arquitectura, es necesario tener en cuenta la aplicación en el sistema. En particular, la gran cantidad de datos, la necesidad de una fracción de la base de datos .
Tales como: registro de datos de usuario, el volumen, y hay que considerar sub-biblioteca subtabla
Una vez que la base de datos ha sido dividido, entonces un montón de dolores de cabeza, uno de los cuales es un problema de la transacción . A continuación, nos fijamos en el problema es cómo aparecerá en?
escena
Figura en un primer llegado,
Después de dividir los datos, es similar al esquema anterior
Calculamos el ejemplo anterior, el usuario tomó los datos de los usuarios una vez decenas de millones en la necesidad de sub-biblioteca subtabla ; higo en tres puntos de la base de datos, cada biblioteca para asegurar una alta disponibilidad.
Este diseño de la arquitectura, la transacción se encuentra un problema, nos fijamos en el escenario de negocio específica: Una transferencia de usuario 100 yuanes al usuario B, este negocio es relativamente simple, tenemos que analizar las medidas que específicos :
1, la cuenta del usuario de A a deducir 100 yuanes 2, entonces los del usuario B cuenta adicional 100
La lógica es simple, el pseudocódigo
El código es relativamente clara, siento no hay ningún problema, entonces tenemos que analizar el problema?
problema
Vemos en el negocio de transferencia, hay dos pasos, un usuario A está deduciendo operación dinero, un usuario está operando B más dinero
Si se encuentra en la misma base de datos, puede asegurarse de que esta operación de dos pasos, al mismo tiempo tampoco tiene éxito o no éxito al mismo tiempo. Esto asegura que la transferencia de la consistencia de datos.
Sin embargo, si los datos de usuario de un clúster A, B, el usuario B en el cluster hacen? Debido a que no son la misma transacción en: un usuario ha encargado el mismo éxito, pero el usuario B más el dinero fallado, sino que sería hoyo, datos incompletos arriba.
Este problema es similar a la arquitectura de micro-servicio será más , ya que todos los servicios son módulos independientes, todas las llamadas de larga distancia , ninguna ley en la misma transacción, la transacción se encontrará con problemas.
¿Cómo se puede solucionar? Hay algunos programas en línea, tales como: compromiso en dos fases, TCC, etc., no es comúnmente esquema de consistencia eventual. Today'll informarle sobre cómo utilizar el middleware de mensajería para resolver . Luego ponemos el plan para ajustar la apariencia, añadir middleware de mensajería , y ver cómo la optimización.
Soluciones de middleware de mensajería
La cifra es el uso de la mensajería middleware manera, la deducción del tráfico asíncrono, y el negocio de dinero , después de una carga exitosa, envía un "mensaje de éxito de débito" para el middleware de mensajería ; complemento negocio de dinero Suscribirse "mensaje de éxito de débito" , a continuación, el usuario B al dinero complemento
El sistema sabe cómo el usuario B, más dinero? Es el cuerpo del mensaje, que contiene la cuenta de origen y el ID de cuenta de destino, y la cantidad de dinero
Esta vez quizás amiguitos le pedirán, también debería ser un problema, a la derecha: Escena uno: Después de que el primer mensaje de carga
La primera carga y luego enviar un mensaje, enviar el mensaje en caso de fallo, que el usuario B no sería capaz de agregar dinero
Que el orden de los ajustes Escena 2: primer mensaje, después de la deducción
Débito éxito mensaje se envió con éxito , pero el usuario A cargo fallado , puede agregar dinero para suscribirse al servicio de noticias, el usuario B más dinero
Deberíamos ver un problema, que se no se garantiza de débito y enviarles mensajes, y el éxito o el fracaso, al mismo tiempo , lo que resulta en datos inconsistentes.
programa de servicios RocketMQ
Debido a los problemas anteriores, RocketMq el middleware de mensajería mensaje se divide en dos etapas : fase Preparado y etapa Preparado fase de validación (etapa preliminar)
El escenario es principalmente para enviar un mensaje a rocketmq, pero el mensaje se almacena sólo en en commitlog , pero consumeQueue no visible, es el lado del consumidor (extremos de suscripción) no puede ver este mensaje .
cometer / fase de reversión (fase de validación)
El escenario principal es el mensaje preparado se guarda en consumeQueue en que para que los consumidores pueden ver al final de este mensaje , que puede consumir el mensaje .
Utilizamos el diagrama para ilustrar la siguiente:
El proceso completo :
1, antes de deducciones, a enviar un mensaje de disponibilidad
2, después de enviar el mensaje correctamente preparar, ejecutar transacciones de débito locales
3, después de la deducción de éxito, a continuación, enviar un mensaje de confirmación
4, al final del mensaje (negocio de más dinero) se puede ver un mensaje de confirmación, el consumo de este mensaje, más dinero
Confirmación mensaje Descripción
NOTA: El mensaje de confirmación anterior puede comprometer los mensajes pueden ser abonados consumidos; también puede ser una noticia Rollback, a saber, la aplicación de la transacción de débito local no logra enviar el mensaje reversión, el mensaje se elimina la preparación, los abonados no pueden consumir
Analicemos escenario anormal :
Anormal 1: Si envía un mensaje de falla de preparación, el siguiente procedimiento no va a ir; esto es normal y
anormal 2: Si envía un mensaje de éxito preliminar, pero la ejecución de una transacción local falla, esto no es un problema, porque este mensaje no está listo para ser consumido finales suscribirse a finales de los consumidores de la empresa no se ejecutará.
Anormal 3: Si envía una preparación mensaje de error, la transacción local es exitosa, pero no pudo enviar un mensaje de reconocimiento, lo que es un problema, porque el usuario una tarjeta de débito con éxito, pero añadir negocio dinero no está suscrito al mensaje de confirmación, no se puede agregar dinero. Aquí no ha habido datos inconsistentes.
RocketMq que es la forma de resolverlo?
Vuelve RocketMQ
imagen
Cómo RocketMq resolver el problema anterior, la idea central es que el registro volver [estado] , que es RocketMq regularidad transversal commitlog en el mensaje de preparación.
Debido a que el aprovisionamiento de mensaje con el tiempo se convertirá en el mensaje de restauración no actualizada o al mensaje , por lo que el mensaje esté listo para atravesar volver a comprobar el estado de ejecución de la empresa local, si es encontrado sin llevar a cabo un negocio local con éxito en rollBack , si es ejecutado con éxito envía los mensajes de confirmación.
Lo anterior anomalía 3, listo para enviar el mensaje de error, la transacción de débito local es exitosa, pero no pudo enviar un mensaje de reconocimiento, porque RocketMq llevará a cabo una posterior investigación preliminar para el mensaje , compruebe de nuevo después del negocio descubrimiento ha sido acusado con éxito , y luego volver a emitir "para cometer confirmación mensaje " , por lo que añadir dinero a la empresa pueden suscribirse a este mensaje hacia arriba.
De hecho, esta idea también resuelve el anormal 2, porque no hay ninguna transacción local se ejecuta con éxito, volver a RocketMQ negocios, no encontró una ejecución satisfactoria, restauración no actualizada se enviará un mensaje de confirmación, se elimina el mensaje .
Compruebe juez de vuelta si el éxito del negocio
Socios pequeños en la parte posterior comprobación en los negocios, la forma de determinar si la transacción local se ejecuta con éxito ?
Si la transacción local ejecuta un montón de mesas, no es que queremos que esas tablas deben llevarse a cabo para determinar si con éxito ? Esto no es un problema, y los negocios y están acoplando.
¿Hay una mejor manera? Consiste en diseñar una tabla de transacciones , la mesa de negocios y transacciones de unión en la misma transacción local , si la operación es exitosa de débito locales, registros de transacciones deberían haber sido el estado transactionId es "Completado". Cuando RocketMq volver a comprobar, simplemente marque la correspondiente si el estado se transactionId 'Completado' como , sin tener que preocuparse acerca de los datos específicos de la empresa.
Autor: Perdido er
enlace: https: //www.jianshu.com/p/286cac4625b6
Fuente: libros de Jane
tienen derechos de autor por el autor. reimpresión comercial póngase en contacto con el autor autorizada, reimpresión no comercial por favor indique la fuente.
