[Vista previa de la conferencia Yuan Chuang] Día del Programador 1024 (dos días antes), reúnase en la oficina de Open Source China, ¡hablemos de IA! >>>

1. Antecedentes

Antes de describir el concepto de transacciones distribuidas, primero revisemos algunos conceptos relacionados con las transacciones.

1.1 Conceptos básicos de transacciones

Es una unidad de ejecución de programas, en la que todas las operaciones se ejecutan con éxito o todas las ejecuciones fallan, solo la mitad de las operaciones tienen éxito y la otra mitad falla. Por ejemplo, si un código de transacción realiza dos operaciones de actualización de la base de datos, estas dos operaciones de la base de datos se ejecutarán correctamente o se revertirán.

1.2 Características básicas de las transacciones

Sabemos que las transacciones tienen cuatro características muy importantes, a las que solemos llamar (ACID).

Atomicidad: todas las operaciones en una transacción se completan o no se completan por completo y no finalizarán en ninguna etapa intermedia. Si ocurre un error durante la ejecución de la transacción, se restaurará (Rollback) al estado anterior a que comenzara la transacción, como si la transacción nunca se hubiera ejecutado.
Consistencia: la integridad de la base de datos no se ve comprometida antes de que comience la transacción y después de que finalice. Esto significa que los datos escritos deben cumplir plenamente con todas las reglas preestablecidas, incluida la precisión y la concatenación de los datos, y que la base de datos posterior puede completar espontáneamente el trabajo predeterminado.
Aislamiento: la capacidad de la base de datos para permitir que múltiples transacciones simultáneas lean, escriban y modifiquen sus datos al mismo tiempo. El aislamiento puede evitar la inconsistencia de los datos debido a la ejecución cruzada cuando se ejecutan múltiples transacciones simultáneamente. El aislamiento de transacciones se divide en diferentes niveles, que incluyen lectura no confirmada, lectura confirmada, lectura repetible y serializable.
Durabilidad: Una vez completada la transacción, las modificaciones a los datos son permanentes y no se perderán incluso si el sistema falla.

2 transacciones distribuidas

De hecho, el concepto de transacciones distribuidas es esencialmente el mismo que el de las transacciones de bases de datos. Dado que es una transacción, debe cumplir con las características básicas de las transacciones (ACID), sin embargo, la expresión de las transacciones distribuidas es muy diferente de la de las transacciones locales. .

En la era de las transacciones locales, si necesitamos operar varios registros de la base de datos al mismo tiempo y estas operaciones se pueden poner en una transacción, entonces podemos lograrlo a través del mecanismo de transacción proporcionado por la base de datos.

Con el avance de la arquitectura de microservicios, una unidad de ejecución lógica local se ha dividido en múltiples microservicios independientes, y estos microservicios operan diferentes bases de datos y tablas, respectivamente.

Por ejemplo, al asignar una tarea de transporte individual, es necesario generar requisitos, planes y tareas al mismo tiempo, y también llamar a servicios de consulta y servicios de seguros, luego, una vez que ocurra alguna excepción en el servicio, surgirán problemas transaccionales. Aunque nuestra lógica actual puede quedar invalidada por las operaciones, ¿qué pasará después de la automatización en el futuro?

Las transacciones distribuidas están diseñadas para resolver el problema de coherencia de datos entre diferentes nodos en la arquitectura de microservicios (todas las formas son sistemas distribuidos). Este problema de coherencia esencialmente resuelve el problema que las transacciones tradicionales deben resolver, es decir, si una solicitud se encuentra en múltiples cadenas de llamadas de microservicios, el procesamiento de datos de todos los servicios será exitoso o se revertirá. Por supuesto, la forma de los problemas de transacciones distribuidas puede ser bastante diferente de la de las transacciones tradicionales, pero la esencia de los problemas es la misma y todos requieren resolver el problema de la coherencia de los datos.

Hay muchas formas de implementar transacciones distribuidas, la más representativa de las cuales es el protocolo de transacciones distribuidas XA propuesto por el sistema Oracle Tuxedo. El protocolo XA incluye dos implementaciones: compromiso de dos fases (2PC) y compromiso de tres fases (3PC), a continuación, presentaremos los principios de estos dos métodos de implementación respectivamente.

3 Presentación en dos fases (2PC)

El compromiso de dos fases también se llama 2PC (protocolo de compromiso de dos fases), 2PC es un protocolo de compromiso atómico centralizado, fuertemente consistente y muy clásico. La centralización mencionada aquí significa que hay dos roles en el protocolo: uno es el coordinador de transacciones distribuidas (coordinador) y N participantes (participantes).

3.1 Principio de funcionamiento 2PC

La presentación en dos etapas, como su nombre indica, implica dos etapas de presentación: la primera etapa, la etapa de preparación (etapa de votación); la segunda etapa, la etapa de presentación (etapa de ejecución).

3.1.1 Fase de preparación

El iniciador de la transacción distribuida envía una solicitud al coordinador de transacciones distribuidas (Coordinador, también llamado TransactionManager de gestión de transacciones).
El Coordinador envía solicitudes de preprocesamiento de transacciones al Participante A y al Participante B respectivamente, lo que se denomina Preparar, y algunos datos también se denominan "Solicitud de votación".
En este momento, estos nodos participantes generalmente abrirán transacciones de la base de datos local y luego comenzarán a ejecutar transacciones locales de la base de datos. Cada participante de la base de datos ejecuta transacciones localmente y escribe registros locales de Deshacer/Rehacer (los registros de Deshacer registran datos antes de la modificación. Se utiliza para la reversión de la base de datos, el registro de Rehacer registra datos modificados y se utiliza para escribir el archivo de datos después de confirmar la transacción), pero una vez completada la ejecución, la transacción local de la base de datos no se enviará inmediatamente, pero primero se realizará el "Compromiso de votación" al Coordinador. Comentarios e informar los resultados del procesamiento.
Si todos los participantes dan su opinión sobre el "Compromiso de votación" al coordinador, el proceso pasa a la segunda etapa.

3.1.2 Fase de compromiso

1) Si todos los participantes informan que tuvieron éxito, el coordinador enviará una "notificación de confirmación de confirmación global (global_commit)" a todos los participantes, y el participante completará el envío de su propia transacción de base de datos local y responderá con el resultado del envío. al Coordinador Coordinador, y luego el Coordinador Coordinador devolverá el resultado de la finalización del procesamiento de transacciones distribuidas a la persona que llama. Si algún participante falla, la transacción se revierte.

2) Si el participante devuelve el mensaje "Vote_Abort" al coordinador, se devuelve un mensaje de error. En este momento, el Coordinador del coordinador de transacciones distribuidas iniciará un mensaje de reversión de la transacción ("global_rollback") a todos los participantes. En este momento, cada participante revertirá la transacción local, liberará recursos y enviará un "ack" al coordinador. " Confirme el mensaje y el coordinador devolverá el resultado del error en el procesamiento de la transacción distribuida a la persona que llama.

Lo anterior es el proceso básico de envío de dos fases, entonces, de acuerdo con este protocolo de envío de dos fases, ¿se puede resolver el problema de coherencia de datos de los sistemas distribuidos?

3.2 Problemas con 2PC

De hecho, 2PC solo resuelve el problema de coherencia de los datos de una transacción en un sistema distribuido entre múltiples servicios agregando la función del coordinador de transacciones (Coordinador) a través de un proceso de procesamiento de dos etapas.

Los siguientes puntos son algunos de los problemas encontrados en el protocolo de confirmación de dos fases XA:

Problemas de rendimiento: todos los nodos participantes en 2PC bloquean transacciones. Cuando se agota el tiempo de espera de la comunicación en un nodo participante, los demás participantes se bloquearán pasivamente y ocuparán recursos que no se pueden liberar.
Problema de punto único de falla del coordinador: debido a la gran dependencia del coordinador, una vez que el coordinador falla, los participantes todavía están en un estado de recursos bloqueado y no pueden completar la operación de confirmación de la transacción. Aunque un coordinador será reelegido después de que falle, esto no puede resolver el problema del bloqueo de los participantes debido al fracaso del coordinador anterior.
La interrupción de la red provoca una división del cerebro: en la segunda fase, después de que el coordinador envía el comando de confirmación a los participantes, una vez que se produce la fluctuación de la red en este momento, algunos participantes reciben la solicitud de confirmación y la ejecutan, pero otros participantes que no han recibido la La solicitud de confirmación no puede ejecutar la confirmación de la transacción. Esto conduce a inconsistencia de datos en todo el sistema distribuido.

4 Presentación en tres etapas (3PC)

El envío de tres etapas, también conocido como 3PC, agrega la etapa CanCommit sobre la base de 2PC e introduce un mecanismo de tiempo de espera. Una vez que el participante de la transacción no recibe la solicitud de confirmación del coordinador, automáticamente realizará una confirmación local, lo que resuelve de manera relativamente efectiva el problema del punto único de falla del coordinador.

4.1 Principio de funcionamiento de 3PC

4.1.1 Fase CanCommit

El coordinador emite CanCommit a los participantes y realiza operaciones de consulta de transacciones. Solo después de que todos los participantes respondan que sí se puede pasar a la siguiente etapa. (La tabla no está bloqueada en esta etapa, a diferencia de 2pc que comienza a bloquear la tabla en la primera etapa. La primera etapa de 3pc es evitar bloquear la tabla bajo la premisa de que los participantes individuales no tienen la capacidad de realizar transacciones). términos simples Simplemente verifique la salud de su propio estado.
Si algún participante responde No, se interrumpirá toda la transacción distribuida y el coordinador enviará una solicitud de "abortar" a todos los participantes.

4.1.2 Fase previa al compromiso

En la fase uno, si todos los participantes responden Sí, se ingresará a la fase de compromiso previo para el compromiso previo de la transacción. En este momento, el coordinador de transacciones distribuidas enviará una solicitud de PreCommit a todos los participantes y, después de recibirla, los participantes comenzarán a realizar operaciones de transacción y registrarán la información de Deshacer y Rehacer en el registro de transacciones. Una vez que el participante completa la operación de transacción (en este momento se encuentra en el estado de transacción no confirmada), enviará "Ack" al coordinador para indicar que está listo para enviar y que está esperando la siguiente instrucción del coordinador.
El resultado de los comentarios de cualquier participante es No, o el coordinador agota el tiempo de espera mientras espera comentarios del nodo participante (solo el coordinador puede agotar el tiempo de espera en 2PC y no existe un mecanismo de tiempo de espera para los participantes). Se cancelará toda la transacción distribuida y el coordinador enviará una solicitud de "cancelación" a todos los participantes.

4.1.3 Fase de compromiso

En la Fase 2, si todos los participantes pueden realizar el envío de PreCommit, el coordinador cambiará de "Estado de PreCommit" -> "Estado de Compromiso". Luego envíe una solicitud "doCommit" a todos los participantes. Después de recibir la solicitud de confirmación, el participante realiza la operación de envío de la transacción y devuelve el mensaje "Ack" al coordinador. El coordinador completa la transacción después de recibir el mensaje Ack de todos los participantes.
De manera similar, si un nodo participante no completa la retroalimentación previa a la confirmación o la retroalimentación se agota, el coordinador enviará solicitudes de cancelación a todos los nodos participantes, interrumpiendo así la transacción.

En comparación con 2PC, 3PC establece un tiempo de espera tanto para el coordinador como para el participante, lo que resuelve el problema de que el participante no puede comunicarse con el nodo coordinador durante mucho tiempo (el coordinador cuelga) El problema de liberar recursos se debe a que los propios participantes tiene un mecanismo de tiempo de espera y realizará automáticamente confirmaciones locales para liberar recursos después del tiempo de espera. Este mecanismo también reduce el tiempo de bloqueo y el alcance de toda la transacción.
Además, a través del diseño de las tres etapas de CanCommit, PreCommit y DoCommit, en comparación con 2PC, se configura una etapa de búfer adicional para garantizar que el estado de cada nodo participante sea consistente antes de la etapa de envío final.

Desventajas de 3PC:

Si bien 3PC elimina el bloqueo, también introduce un nuevo problema, es decir, después de que el participante recibe el mensaje de precompromiso, si se produce una partición de red, el nodo donde se encuentra el coordinador y el participante no pueden comunicarse normalmente. En este caso, el participante Aún así, confirma la transacción, lo que inevitablemente conducirá a inconsistencia de datos.

5 Asuntos de Compensación (TCC)

TCC, al igual que 2PC y 3PC, es solo una solución de implementación para transacciones distribuidas.

5.1 Principio TCC:

TCC (Probar-Confirmar-Cancelar) también se denomina transacción de compensación. La idea central es: "Para cada operación, se debe registrar una confirmación y compensación (operación de revocación) correspondiente". Se divide en tres operaciones:

Etapa de prueba: principalmente probar el sistema empresarial y reservar recursos, como congelar el inventario.
Etapa de confirmación: confirmar la ejecución de las operaciones comerciales.
Etapa de cancelación: Cancelar la ejecución de operaciones comerciales.

El flujo de procesamiento de las transacciones TCC es similar al envío de dos etapas de 2PC, pero 2PC generalmente está en el nivel de base de datos entre bases de datos, y TCC es esencialmente un 2PC a nivel de aplicación, que debe implementarse a través de la lógica empresarial. La ventaja de esta implementación de transacciones distribuidas es que permite a las aplicaciones definir la granularidad de las operaciones de la base de datos, lo que permite reducir los conflictos de bloqueo y mejorar el rendimiento.

La desventaja es que es muy intrusivo para la aplicación: cada rama de la lógica empresarial necesita implementar las tres operaciones de probar, confirmar y cancelar. Además, su implementación es relativamente difícil y es necesario implementar diferentes estrategias de reversión según los diferentes motivos de falla, como el estado de la red y las fallas del sistema. Para cumplir con los requisitos de coherencia, las interfaces de confirmación y cancelación también deben ser idempotentes.

El diagrama esquemático específico de TCC es el siguiente:

5.2 Notas:

1. Las operaciones comerciales se desarrollan en dos etapas:

Antes de acceder a TCC, las operaciones comerciales se pueden completar en un solo paso, sin embargo, después de acceder a TCC, es necesario considerar cómo dividirlas en dos fases: la verificación y la reserva de recursos se llevan a cabo en la operación de prueba de una etapa, y la operación real es La ejecución de las operaciones comerciales se realiza en la operación de confirmación de la segunda etapa;
el servicio TCC debe garantizar que después de que la operación de prueba de la primera etapa sea exitosa, la operación de confirmación de la segunda etapa debe ser exitosa;

2. Permitir la reversión vacía;

Cuando el coordinador de transacciones llama a la operación de prueba de una etapa del servicio TCC, puede ocurrir un tiempo de espera de red debido a la pérdida de paquetes. En este momento, el coordinador de transacciones activará una reversión de dos etapas y llamará a la operación de cancelación del servicio TCC
; Se recibe una solicitud de cancelación cuando se realiza una solicitud de prueba. Este escenario se denomina reversión vacía; el servicio TCC debe permitir la ejecución de una reversión vacía cuando se implementa;

3. Control antisuspensión;

Cuando el coordinador de transacciones llama a la operación de prueba de una etapa del servicio TCC, puede ocurrir un tiempo de espera debido a la congestión de la red. En este momento, el coordinador de transacciones activará una reversión de dos etapas y llamará a la operación de cancelación del servicio TCC; después eso, la congestión ocurrirá en El servicio TCC recibe el paquete de prueba de la primera etapa en la red y la solicitud de cancelación de la segunda etapa se ejecuta antes de la solicitud de prueba de la primera etapa. Al implementar el servicio TCC, los usuarios deben permitir la reversión
vacía , pero se niega a ejecutar la reversión vacía. Llega la siguiente fase de la solicitud de prueba;

4. Control idempotente:

Ya sea la retransmisión de paquetes de datos de red o la ejecución de compensación de transacciones anormales, las operaciones de prueba, confirmación o cancelación del servicio TCC se ejecutarán repetidamente. Al implementar el servicio TCC, los usuarios deben considerar el control idempotente, es decir, el ejecución de Intentar, Confirmar y Cancelar Los resultados comerciales son los mismos si se ejecutan una y varias veces;

5. Control de visibilidad de los datos comerciales;

La operación de prueba de la primera etapa del servicio TCC reservará recursos. Antes de ejecutar la operación de la segunda etapa, si otras transacciones necesitan leer los datos de recursos reservados, cómo mostrar los datos comerciales en el estado intermedio al usuario requiere que el negocio Pensar claramente al implementar, el principio de diseño habitual es "es mejor no mostrar nada o menos que mostrar demasiado o mal";

6. Control de acceso simultáneo a datos comerciales;

Después de que los recursos se reserven en la operación de prueba de la primera etapa del servicio TCC, los recursos reservados no se liberarán hasta que se ejecute la operación de la segunda etapa; si otras transacciones distribuidas modifican estos recursos comerciales en este momento, se producirán problemas de concurrencia de transacciones distribuidas. ocurrir;
Al implementar servicios TCC, los usuarios deben considerar el control de concurrencia de los datos comerciales y tratar de minimizar la granularidad del bloqueo lógico para maximizar la concurrencia de las transacciones distribuidas;

6 Hmily

Hmily (Cuánto te amo)
marco de código abierto tcc de transacciones distribuidas de alto rendimiento. Desarrollado en base al lenguaje Java (JDK1.8), admite dubbo, springcloud, motan y otros marcos RPC para transacciones distribuidas.

Propiedades del marco

Admite transacciones anidadas (soporte de transacciones anidadas).
El uso del marco disruptor para la lectura y escritura asincrónica de registros de transacciones no tiene ninguna diferencia en el rendimiento con respecto al marco RPC.
Admite el inicio de proyectos SpringBoot-starter y es fácil de usar.
El marco RPC admite: dubbo, motan, springcloud.
Soporte de almacenamiento de transacciones local: redis, mongodb, zookeeper, file, mysql.
Soporte de serialización de registros de transacciones: java, hessian, kryo, protostuff.
Adopta la idea de aspecto de Aspect AOP para integrarse perfectamente con Spring y, naturalmente, admite la agrupación en clústeres.
Tiene un proyecto de demostración de escenario de transacción distribuida clásico incorporado y una interfaz visual swagger-ui para una experiencia rápida.

6.1 Principio familiar y diagrama de flujo

Esquemático:

diagrama de flujo:

7. Referencias

https://dromara.org/website/zh-cn/docs/hmily/index.html
https://houbb.github.io/2018/10/30/hmily
https://developer.aliyun.com/article/609854
https://blog.csdn.net/bjweimengshu/article/details/86698036
https://blog.csdn.net/u014296316/article/details/90185589

Autor: JD Logística Song Le

Fuente: Comunidad de desarrolladores de JD Cloud Ziyuanqishuo Tech Indique la fuente al reimprimir

Una breve discusión sobre transacciones y soluciones distribuidas | Equipo de tecnología de JD Logistics