No somos ajenos a las transacciones. Las transacciones a menudo nos referimos a transacciones independientes, es decir, transacciones locales. ¿Qué es la transacción distribuida? Una transacción distribuida es una transacción compuesta de múltiples transacciones locales , y generalmente aparece en un escenario distribuido.
Por ejemplo, en la plataforma de comercio electrónico, cuando hacemos compras, el proceso de realizar un pedido y el pago parece hacerse de una vez, pero detrás de esto puede estar la cooperación de múltiples sistemas. Sistema de pedidos, sistema de pagos, sistema logístico, etc. Estos sistemas se implementan en diferentes servidores y ejecutan varias transacciones. Para las plataformas de comercio electrónico, esta es una transacción distribuida.
Las transacciones locales son fáciles de resolver. Existe un conjunto de mecanismos de transacción listos. Las transacciones distribuidas son mucho más complicadas que las transacciones locales. ¿Cómo implementar transacciones distribuidas? Hay alrededor de 3 soluciones:
- Un acuerdo de presentación de dos fases basado en el acuerdo XA .
- Presentar el acuerdo en tres etapas .
- Consistencia final basada en MQ .
Presentación en dos fases basada en el protocolo XA
El protocolo XA fue propuesto por primera vez por Tuxedo y entregado a la organización X / Open como el estándar de interfaz entre el administrador de recursos (base de datos) y el administrador de transacciones. Actualmente, los principales fabricantes de bases de datos como Oracle, Informix, DB2 y Sybase brindan soporte para XA. ---- Fuente Enciclopedia Baidu
La confirmación de dos fases también se llama 2PC , el protocolo de confirmación de dos fases. Primero, hay dos roles en la presentación de dos fases:
- Participantes : el administrador de recursos local, el ejecutor de la transacción, es decir, cada sistema empresarial.
- Coordinador : El cerebro de las transacciones distribuidas, responsable de dirigir y coordinar el envío / reversión de transacciones por diversos sistemas comerciales.
La llamada presentación en dos etapas se refiere a las dos etapas de votación y compromiso : al igual que el sistema electoral, la votación es primero y luego se toma la decisión.
En la fase de votación , el coordinador inicia una solicitud para realizar una operación de transacción (solicitud CanCommit) al participante, y espera a que el participante responda.
Después de recibir la solicitud, el participante ejecuta la operación de solicitud de transacción, registra la información de registro pero no la envía. Después de que la grabación es exitosa, se envía un mensaje "Sí" al coordinador, indicando que la operación de envío está aprobada. De acuerdo con esta operación . Tenga en cuenta que este proceso bloqueará los datos.
El diagrama de flujo de la etapa de votación es probablemente así:
En la fase de presentación , después de recibir las respuestas de todos los participantes, el coordinador envía una solicitud de presentación o reversión a los participantes de acuerdo con la información devuelta.
-
Si los mensajes de respuesta recibidos son todos "Sí", envíe un mensaje "DoCommit" al participante , el participante completa otras operaciones de la transacción local y libera recursos, y luego envía un mensaje "HaveCommitted" al coordinador;
-
Si el mensaje recibido por el coordinador contiene un mensaje "No" o si hay un participante que no responde dentro de un tiempo especificado, el mensaje "DoAbort" se envía a todos los participantes , y el participante que envió "Sí" realizará la operación de acuerdo con lo anterior El registro de reversión en ese momento revierte la operación, y luego todos los participantes enviarán un mensaje "HaveCommitted" al coordinador;
El proceso de la fase de presentación se muestra aproximadamente en la siguiente figura:
El protocolo de confirmación de dos fases es fácil de entender. El algoritmo de confirmación de dos fases basado en XA satisface las características ACID de las transacciones. Parece perfecto, pero todavía hay muchas deficiencias. Los principales problemas son los siguientes:
- Problema de bloqueo sincrónico : durante la ejecución de la confirmación de dos fases, todos los nodos participantes están bloqueando transacciones. Los participantes bloquearán los datos y otros visitantes serán bloqueados si desean acceder a los datos.
- Punto único de falla . En el acuerdo de presentación de dos fases, solo hay un coordinador. Una vez que el coordinador envía una falla, todo el sistema estará parado. Especialmente durante la fase de presentación, si el coordinador cuelga, el participante siempre esperará a que el coordinador responda y será bloqueado.
- Inconsistencia de datos : durante la fase de envío, después de que el coordinador envía una solicitud de DoCommit a los participantes, debido a la fluctuación de la red o una falla del coordinador en el proceso de envío de la solicitud, solo una parte de los participantes recibirá la solicitud de envío y realizará la operación de envío. Pero la otra parte de los participantes que no recibió la solicitud de envío no puede realizar el envío de la transacción. El problema de la inconsistencia de datos apareció en todo el sistema distribuido.
Presentación trifásica
El protocolo de confirmación de tres fases (3PC) es una mejora en el protocolo de confirmación de dos fases (2PC) . Resuelto algunos problemas de la presentación en dos fases, la mayor diferencia entre la presentación en tres fases y la segunda fase es la introducción del mecanismo de tiempo de espera y la fase de preparación .
Permítanme hablar sobre el mecanismo de tiempo de espera primero. En la segunda etapa de presentación, solo el coordinador tiene un mecanismo de tiempo de espera. Si el coordinador no recibe una respuesta del participante dentro del tiempo especificado, enviará o terminará la transacción completa de acuerdo con el estado actual. El participante no tiene un mecanismo de tiempo de espera, por lo que ha estado esperando, que también es el problema de presentar un solo punto de falla en la segunda etapa. En la presentación de tres fases, se introdujo un mecanismo de tiempo de espera en el coordinador y los participantes al mismo tiempo . Si el coordinador o participante no recibe una respuesta de otros nodos dentro del tiempo especificado, elegirá comprometer o terminar la transacción completa de acuerdo con el estado actual.
La presentación de tres fases en realidad divide la fase de presentación en la presentación de dos fases en dos. Las tres fases específicas en el acuerdo de presentación de tres fases son: CanCommit, PreCommit, DoCommit tres fases
La fase CanCommit es similar a la fase de votación de 2PC: el coordinador envía una operación de solicitud (solicitud CanCommit) al participante, preguntando si el participante puede realizar la operación de confirmación de transacción, y luego espera la respuesta del participante; después de que el participante recibe la solicitud CanCommit, Responda Sí, indicando que la transacción se puede ejecutar sin problemas; de lo contrario, responda No.
En la fase PreCommit , de acuerdo con la fase de confirmación similar en la confirmación de dos fases, de acuerdo con el resultado devuelto por la fase CanCommit, se determina si se puede realizar la operación PreCommit.
En este momento, hay dos situaciones: si todos los participantes responden "Sí" , el flujo de ejecución es así:
- 1. El coordinador envía una solicitud de confirmación previa : el coordinador envía una solicitud de confirmación previa al participante para que ingrese a la fase de presentación previa.
- 2. Compromiso previo a la transacción : los participantes realizan operaciones de transacción después de recibir la solicitud de PreCommit y registran la información de Deshacer y Rehacer en el registro de transacciones.
- 3. Respuesta de respuesta : si el participante ejecuta con éxito la operación de transacción, devuelve una respuesta ACK y comienza a esperar la instrucción final.
Si un participante devuelve "No", o el coordinador no recibe una respuesta del participante dentro del tiempo especificado , la transacción se interrumpirá . El proceso es este:
- 1. Enviar una solicitud de interrupción : el coordinador envía un mensaje "Abortar" a todos los participantes.
- 2. Interrumpa la transacción : después de que el participante recibe el mensaje "Abortar", o no recibe el mensaje del coordinador después del tiempo de espera, la transacción se interrumpe.
En la fase DoCommit , la transacción se envía realmente, el coordinador decide si ingresar a la fase de compromiso o la fase de interrupción de la transacción en función de la información devuelta por los participantes en la fase de PreCommit.
El proceso de la fase de presentación es el siguiente:
- 1. Enviar una solicitud de envío : el coordinador recibe las respuestas de Ack enviadas por todos los participantes, ingresa el estado previo al envío al estado de envío y envía un mensaje DoCommit a todos los participantes.
- 2. Envío de la transacción : después de que los participantes reciben el mensaje DoCommit, envían formalmente la transacción. Después de completar la confirmación de la transacción, libere todos los recursos bloqueados.
- 3. Respuesta de respuesta : después de que el participante envíe la transacción, envíe una respuesta de reconocimiento al coordinador.
- 4. Completar la transacción : después de recibir las respuestas de Ack de todos los participantes, el coordinador completa la transacción.
Durante la fase de interrupción de la transacción , el proceso es el siguiente:
- 1. Enviar solicitud de interrupción : el coordinador envía solicitudes de cancelación a todos los participantes.
- 2. Revertir la transacción : después de recibir el mensaje Anular, el participante utiliza la información Deshacer registrada en la fase Precommitir para realizar la operación de reversión de la transacción y liberar todos los recursos bloqueados.
- 3. Resultado de la retroalimentación : después de que el participante completa la reversión de la transacción, envía un mensaje de reconocimiento al coordinador.
- 4. Interrumpir la transacción : después de recibir el mensaje Ack del participante, el coordinador interrumpe la transacción y finaliza la transacción.
El esquema de consistencia final basado en un mensaje distribuido
Ya sea un compromiso de dos fases o un compromiso de tres fases, todos son muy consistentes y satisfacen el principio de transacciones ACID. Todos tienen dos problemas comunes:
- 1. La necesidad de bloquear datos reduce el rendimiento del sistema .
- 2. Debido a la red y otras razones, el problema de consistencia de datos no se ha resuelto por completo.
La solución distribuida basada en el mensaje MQ no es la misma: no utiliza una consistencia fuerte, sino una consistencia final , que es la teoría BASE. Y somos asíncronos hasta MQ, por lo que el rendimiento es relativamente rápido, se puede decir que el problema causado por los dos métodos anteriores está perfectamente resuelto.
La idea de resolver transacciones distribuidas basadas en middleware de mensajes MQ es esta: principalmente basada en la confiabilidad de la entrega de mensajes MQ, después de enviar transacciones distribuidas a middleware MQ, el middleware persistirá en la transacción, lo cual es muy importante para asegurar el mensaje No perdido El consumidor final consume de forma asíncrona. Si nos encontramos con una falla, debido a que nuestro mensaje es persistente, podemos continuar reintentando de acuerdo con las reglas comerciales. Si es necesario, compensa manualmente para garantizar la consistencia final de los datos.
Con respecto al esquema de consistencia final basado en mensajes distribuidos, voy a abrir un capítulo separado basado en RocketMQ y hablaré en detalle sobre esto, así que no entraré en detalles aquí.
Bienvenido a prestar atención al número público [ Internet flat brother ]. Preocupado por este programador de Internet que secretamente roba vidas, espero que usted y yo podamos progresar juntos. Lo mejor hoy es lo más bajo mañana.