[Distribuido] -Transacciones distribuidas

prefacio

¿Qué es una transacción distribuida?

Cualquiera que haya estudiado sistemas de bases de datos y MySQL sabe acerca de las transacciones, pero dichas transacciones en un entorno de base de datos independiente son transacciones locales, es decir, todas las operaciones de la transacción solo deben realizarse en la misma fuente de datos.

Las transacciones distribuidas son otro tipo de transacciones que aparecen en un entorno de sistema distribuido. Se diferencian de las transacciones locales en que las operaciones involucradas en la misma transacción están dispersas en diferentes fuentes de datos y diferentes fuentes de datos se distribuyen en diferentes fuentes de datos. luego, si la transacción se va a ejecutar con éxito, es necesario garantizar que las operaciones en estos diferentes nodos sean exitosas; si la transacción no se ejecuta, es necesario asegurarse de que las operaciones en estos diferentes nodos se reviertan. Además, la coordinación entre nodos debe completarse a través de la comunicación de red, y la existencia de la red aumenta la dificultad de las transacciones distribuidas. Con todo, las transacciones distribuidas tienen como objetivo garantizar la coherencia de los datos en diferentes bases de datos.

Razones para las transacciones distribuidas

1. En un entorno de sistema distribuido, todo el sistema adopta una arquitectura de microservicios y se compone de múltiples servicios diferentes, cada servicio tiene su propia base de datos correspondiente. EntoncesUna función empresarial puede implicar diferentes servicios.Por ejemplo, la función de pedidos puede involucrar servicios comerciales, servicios de pedidos, etc. Para garantizar que toda la función no afecte la coherencia de los datos de cada base de datos involucrada, es necesario introducir transacciones distribuidas para la coordinación.
2. Es posible que algunas funciones no impliquen múltiples servicios, pero los datos que necesitan para operar se distribuyen en diferentes bases de datos. Por ejemplo, cuando la presión de concurrencia de una base de datos de una sola máquina es demasiado grande o la cantidad de datos es demasiado grande, tomaremosSubbase de datos y subtablamétodo de optimización, luego de dividir las bases de datos y tablas, es posible que los datos involucrados en ciertas funciones se divida en dos bases de datos; por otro ejemplo, los datos de los usuarios en diferentes regiones pueden almacenarse enBases de datos de diferentes regiones., cuando una función involucra a varios usuarios, como la función de transferencia, es necesario modificar los datos de ambos usuarios.

Ya sea que los datos se divida a nivel de servicio o a nivel de base de datos , en resumen, dado que implica la modificación de datos en múltiples bases de datos, es necesario introducir transacciones distribuidas para coordinar y garantizar la coherencia.

solución

Antes de considerar soluciones de transacciones distribuidas, una de las preguntas más prioritarias que debemos considerar es si realmente necesitamos introducir transacciones distribuidas. Porque no importa qué solución se adopte, la introducción de transacciones distribuidas inevitablemente aumentará la complejidad del sistema. Deberíamos considerar si podemos fusionar los servicios involucrados en el negocio en un solo servicio y utilizar la solución de transacción independiente tradicional. Si esto no es posible, deberíamos introducir una solución de transacción distribuida.

2 piezas

2PC se refiere al compromiso de dos fases, que es una solución de coherencia sólida. La función de la fuente de datos se denomina administrador de recursos y el administrador de transacciones se presenta como coordinador.

La presentación de toda la transacción se divide en dos fases, la fase de preparación y la fase de presentación . En la fase de preparación, el administrador de transacciones envía un comando a cada administrador de recursos para permitir que cada administrador de recursos ejecute la transacción sin confirmarla, y luego responde al administrador de transacciones con el resultado de la ejecución, es decir, éxito o fracaso.

Cuando el administrador de transacciones recibe respuestas de cada participante, ingresa a la fase de confirmación. La fase de confirmación no es necesariamente una transacción de confirmación, pero también puede ser una transacción de reversión: si todos los participantes en la primera fase devuelven resultados exitosos, entonces el coordinador envía un comando de transacción de confirmación a todos los participantes y luego espera a que se envíen todas las transacciones. exitosamente. Devuelve información sobre la ejecución exitosa de la transacción al cliente; por el contrario, si un participante devuelve un resultado fallido en la primera etapa, el coordinador enviará un comando para revertir la transacción a cada participante y finalmente devuelve información sobre la ejecución exitosa de la transacción al cliente. fracaso de la transacción.

Analisis fallido

1. Si el coordinador no recibe respuestas de todos los participantes en la primera fase del comando, puede deberse a razones de red o el participante está inactivo, entonces el coordinador considerará que la ejecución de la transacción falló después del tiempo de espera, ingresará directamente a la segunda fase y dejará transacción de reversión de cada participante
2. Si el coordinador no recibe todas las respuestas a tiempo en la segunda fase, el coordinador solo puede volver a intentarlo porque algunos participantes pueden haber ejecutado con éxito el comando. Para que los datos sean consistentes, solo puede continuar enviándolos a los participantes que no responden. , ya sea un comando de confirmación o un comando de reversión

defecto

1. Problema de punto único de falla : la ejecución y envío de transacciones requieren la coordinación del coordinador. Si el coordinador falla, toda la transacción no puede continuar.
2. Problema de rendimiento : durante toda la transacción, los recursos de la base de datos de cada nodo están ocupados. Solo después de que se ejecuta el comando de confirmación o reversión del coordinador de la segunda fase, los participantes pueden liberar los recursos de la base de datos. Todo el proceso está en un estado de bloqueo sincrónico, lo que reduce la eficiencia operativa, la experiencia interactiva y el rendimiento. Una vez que el problema de fluctuación de la red es grave, el tiempo de bloqueo será mayor.
3. Problema de tolerancia a fallas : la coordinación necesita recibir respuestas de todos los participantes antes de enviar el siguiente comando a la siguiente fase. Una vez que un participante falla, toda la transacción solo puede fallar y revertirse, o incluso no finalizar normalmente.

3 piezas

3PC surgió para resolver algunos problemas de 2PC. Dividió la fase de preparación en 2PC en dos fases, por lo que contiene tres fases en total, a saber, la fase de preparación puede comprometerse, la fase de precompromiso, la fase de envío es comprometerse, en En la fase de preparación, se preguntará a cada participante si puede ejecutar la transacción . Si todos los participantes responden que sí, ingresarán a la fase de precompromiso . La precompromiso es en realidad la fase de preparación en 2PC, donde la transacción se ejecuta pero no se envía. Y luego la fase de envío final es la fase de confirmación en 2PC, que confirma o revierte la transacción.

Mejoras respecto al 2PC

1. La introducción de la operación de consulta en la fase de confirmación puede unificar el estado entre los participantes y facilitar que el coordinador comprenda el estado de cada participante. Específicamente,Una vez que un participante se encuentra en la etapa de preenvío o envío, significa que cada participante ha pasado por la etapa de preparación y todas las respuestas dadas en la etapa de preparación son positivas., entonces los comandos posteriores que se deben ejecutar son los comandos para confirmar la transacción, sin considerar otros factores; y si no hay operación de consulta en la etapa de confirmación, pero como 2PC, la primera etapa es ejecutar la transacción pero no confirmar él.Si el coordinador y un participante caen después de la primera fase, entonces el nuevo coordinador no sabe si el participante caído tuvo éxito o falló, y no sabe si emitir una transacción de confirmación en la segunda fase. revertir la transacción, entonces 3PC resuelve este problema en comparación con 2PC

2. Además, 3PC también introduce un mecanismo de tiempo de espera entre los participantes , que resuelve el problema del punto único de falla del coordinador en 2PC. En 2PC, si el coordinador cae después de la primera fase de ejecución, los participantes bloquearán y esperarán la orden del coordinador en la segunda fase. En 3PC, si el participante se agota mientras espera la orden en la fase de envío, entonces el los participantes enviarán la transacción ellos mismos y ya no esperarán; si la espera del comando previo a la confirmación se agota, el participante finalizará directamente la transacción, porque no se realizan operaciones de escritura durante la fase de preparación y no hay necesidad de confirmar o revertir, pensar directamente que el negocio ha terminado

defecto

1. Problema de rendimiento : en comparación con 2PC, hay una etapa más y el rendimiento ha disminuido.
2. Problema de inconsistencia de datos : los participantes enviarán la transacción ellos mismos después de que expire el comando en la fase de envío en espera, pero es posible que la operación de reversión debería haberse realizado. En este momento, algunos participantes retrocedieron normalmente y algunos participantes confirmaron la transacción. Debido al tiempo de espera, se produce una inconsistencia en los datos.

TCC

2PC y 3PC son soluciones a nivel de base de datos, es decir, coordinación interna entre múltiples bases de datos. No podemos interferir, solo necesitamos iniciar transacciones y recibir resultados. Y TCC involucra el nivel empresarial.

TCC se refiere a Intentar-Confirmar-Cancelar. Try se refiere a reserva, es decir, la reserva y bloqueo de recursos; Confirm se refiere a confirmación, para ejecutar realmente la transacción; Cancel se refiere a revocación, es decir, cancelar la acción en la fase de reserva. Específicamente, antes de ejecutar una transacción, se debe realizar una operación de reserva en las fuentes de datos involucradas en cada operación. Si cada fuente de datos se reserva con éxito, se realizará una operación de confirmación. Si una operación de reserva falla, se realizará una revocación. funcionar

Además de las llamadas comerciales y las fuentes de datos, también se introduce la función del administrador de transacciones, que es responsable de registrar el estado de las transacciones globales y realizar operaciones de confirmación o reversión para controlar la coherencia de los datos.

Entonces, en una solución como TCC, cada negocio que involucra transacciones distribuidas debe dividirse en tres partes: probar, confirmar y cancelar para la operación, por lo que decimos que involucra el nivel comercial y es altamente intrusivo para el negocio. Las operaciones correspondientes necesitan debe diseñarse de acuerdo con la lógica empresarial específica de escenarios específicos, por lo que la cantidad de desarrollo de código también aumentará en consecuencia.

Pero también se debe a que muchas cosas se completan en la capa empresarial, por lo que es más versátil y tiene un alcance de aplicación más amplio: se puede completar en bases de datos y sistemas empresariales.

defecto

La deficiencia más destacada es la naturaleza altamente intrusiva del negocio mencionado anteriormente.

tabla de mensajes locales

2PC, 3PC y TCC son en realidad soluciones de coherencia sólidas, y las siguientes son soluciones de coherencia finales.

La tabla de mensajes locales está diseñada aprovechando al máximo el hecho de que las transacciones distribuidas son iguales a múltiples transacciones locales.

Habrá una tabla de mensajes local en la fuente de datos, y cada transacción distribuida corresponderá a un mensaje, registrando el estado de ejecución, el tiempo de ejecución y otra información de la transacción. Al ejecutar el negocio, la ejecución del negocio y la inserción de la tabla de mensajes se colocarán en una determinada transacción local. De acuerdo con las características de la transacción local, se puede asegurar que este negocio debe ejecutarse con éxito cuando se envíe el mensaje. escrito . Luego puede llamar a la siguiente empresa en la transacción distribuida. Si la llamada es exitosa, puede cambiar el estado del mensaje correspondiente a toda la transacción a exitosa; si la llamada falla, puede configurar una tarea programada para leer el mensaje local . tabla regularmente. Filtre los mensajes que aún no han tenido éxito y luego llame al servicio correspondiente . Si la actualización del servicio es exitosa, cambie el estado del mensaje. Si necesita volver a intentarlo, debe garantizar la idempotencia del servicio correspondiente y, en general, debe establecer el número máximo de reintentos, que puede ser configurado por el usuario. Si se excede el número máximo de reintentos, se registrarán los registros. y se informará la alarma, permitiendo la intervención manual.

defecto

Si una operación falla, siempre se volverá a intentar sin retroceder ni deshacer la operación. Por lo tanto, esta solución no admite la reversión . Si se necesita una operación de reversión, no se debe adoptar esta solución.

transacción MQ

Las transacciones MQ son similares a las tablas de mensajes locales, excepto que las tablas de mensajes locales están divididas e implementadas en MQ.

Específicamente, un servicio primero envía un medio mensaje correspondiente a la transacción distribuida a MQ . El medio mensaje significa que el mensaje es invisible para los consumidores. Después de enviar con éxito el medio mensaje, el remitente ejecuta su propia transacción local y luego envía un mensaje de confirmación o reversión a MQ de acuerdo con el resultado de la ejecución. Si es un mensaje de confirmación, el suscriptor puede recibirlo y luego realizar el correspondiente operación y consume el mensaje; si es Rollback, entonces el suscriptor no recibirá este mensaje, lo que equivale a que la transacción no se ejecute.

Además, el remitente debe proporcionar una interfaz de compensación para verificar el estado de la transacción . Cuando MQ descubre que la mitad de los mensajes no han recibido la confirmación o reversión correspondiente dentro de un período de tiempo, puede usar la interfaz de verificación para verificar si la transacción del remitente se ejecutó exitosamente y luego ejecute Commit o Rollback.

Si la operación del suscriptor falla, también es necesario volver a intentarlo y también se debe considerar la cuestión de la idempotencia y el número de reintentos.

defecto

Igual que la tabla de mensajes local, no se admiten transacciones de reversión

Asuntos de saga

La idea central de las transacciones Saga es dividir una transacción larga distribuida en múltiples transacciones cortas locales, y el coordinador de transacciones Saga coordina la ejecución de cada transacción corta. Si cada transacción corta finaliza normalmente, toda la transacción distribuida se completará normalmente. ;Si un paso falla, las operaciones de compensación se llaman en orden inverso.

Específicamente, cada transacción de Saga se divide en múltiples subtransacciones ti _, y cada ti _es una transacción local. Cada ti _tiene una acción de compensación correspondiente c _i . La acción de compensación se utiliza para deshacer los resultados causados ​​por ti, lo que equivale a una operación de deshacer _.

Supongamos que una transacción distribuida se puede dividir en n subtransacciones t ₁ a t _n . Si cada subtransacción se puede ejecutar con éxito, entonces el orden de ejecución final de toda la transacción Saga es t ₁ , t ₂ , t ₃ ,. .., t _n , El resultado de toda la transacción de Saga también es una ejecución exitosa
. Si alguna subtransacción no se ejecuta, entonces se debe adoptar una estrategia de recuperación.

Las estrategias de recuperación se dividen en dos tipos en Saga:

1. Recuperación hacia atrás : Suponiendo que la subtransacción tj _falla , entonces es necesario realizar las acciones de compensación de todas las subtransacciones anteriores, cancelar los resultados de ejecución de cada subtransacción y así cancelar el efecto de toda la transacción Saga. la secuencia de ejecución final de toda la transacción Saga es t ₁ ,t ₂ ,…,t _j ,c _j ,c _j-1 ,…,c ₂ ,c ₁
2. Recuperación directa : esta estrategia es adecuada para escenarios que deben tener éxito. Cuando t _{j falla, t j} continuará reintentándose hasta que la ejecución sea exitosa y luego continuará ejecutando subtransacciones posteriores hasta que la última subtransacción tenga éxito. La secuencia de ejecución es similar a: t ₁ , t ₂ ,…, t _j (fallo), t _j (reintento),…, t _n . En este caso, no es necesaria ninguna acción compensatoria c _i .

La transacción de Saga se divide en múltiples subtransacciones y, cuando se ejecuta una determinada subtransacción, otras transacciones no bloquearán los recursos, lo que puede provocar que los efectos de algunas subtransacciones sean sobrescritos por otras transacciones antes de que se complete la transacción de Saga. completado. . Por lo tanto, toda la transacción de Saga no está aislada del mundo exterior.

defecto

En primer lugar, como se mencionó anteriormente, las subtransacciones no bloquearán los recursos cuando otras transacciones no se completen, por lo que no se aislará toda la transacción distribuida.Otras transacciones pueden sobrescribir algunos de los resultados generados por la transacción distribuida, destruyendo así la situación general. Coherencia de los datos;
en segundo lugar, es necesario definir adicionalmente las acciones de compensación correspondientes para cada subtransacción.