Comprensión profunda de las transacciones distribuidas y soluciones para transacciones distribuidas en alta concurrencia
1. ¿Qué es una transacción distribuida?
Una transacción distribuida significa que los participantes de la transacción, el servidor que admite la transacción, el servidor de recursos y el administrador de transacciones se encuentran en diferentes sistemas distribuidos en diferentes nodos. Lo anterior es la explicación de la Enciclopedia Baidu. En pocas palabras, una operación grande se compone de diferentes operaciones pequeñas. Estas pequeñas operaciones se distribuyen en diferentes servidores y pertenecen a diferentes aplicaciones para garantizar que todas estas pequeñas operaciones tengan éxito. fallar todo. Básicamente, las transacciones distribuidas tienen como objetivo garantizar la coherencia de los datos en diferentes bases de datos.
2. Razones para la generación de transacciones distribuidas
2.1. Subbase de datos y subtablas de la base de datos
Cuándo los datos se generan mediante una sola tabla de base de datos. un año supera los 1000 W, entonces es necesario considerar la subbase de datos y la subbase de datos de tabla. Los principios específicos de la subbase de datos y la subbase de datos de tabla no los explicaré aquí. En pocas palabras, la base de datos original se ha convertido en varias bases de datos. En este momento, si una operación accede tanto a la biblioteca 01 como a la biblioteca 02 y se debe garantizar la coherencia de los datos, se deben utilizar transacciones distribuidas.
2.2. Aplicación de SOA
La denominada SOA es el negocio orientado a servicios. Por ejemplo, originalmente una sola máquina admitía todo el sitio web de comercio electrónico, pero ahora todo el sitio web ha sido desmantelado y separado en el centro de pedidos, el centro de usuarios y el centro de inventario. Para el centro de pedidos, existe una base de datos especial para almacenar información de pedidos, el centro de usuarios también tiene una base de datos especial para almacenar información de usuarios y el centro de inventario también tiene una base de datos especial para almacenar información de inventario. En este momento, si desea operar pedidos e inventario al mismo tiempo, implicará la base de datos de pedidos y la base de datos de inventario. Para garantizar la coherencia de los datos, debe utilizar transacciones distribuidas.
Las dos situaciones anteriores tienen diferentes apariencias, pero la esencia es la misma, ¡ambas porque hay más bases de datos para operar!
3. Características ACID de las transacciones
3.1 Atomicidad (A)
La llamada atomicidad significa que todas las operaciones en toda la transacción, ya sea Hazlo. todo o no hacer nada, no hay término medio. Si se produce un error durante la ejecución de la transacción, todas las operaciones se revertirán y toda la transacción será como si nunca se hubiera ejecutado.
3.2.Consistencia (C)
La ejecución de las transacciones debe garantizar la coherencia del sistema. Tomemos como ejemplo la transferencia. a En la transacción, A transfiere con éxito 50 yuanes a B, luego, no importa cuántas concurrencias haya, pase lo que pase, siempre que la transacción se ejecute con éxito, la cuenta final A debe ser de 450 yuanes y la cuenta B Debe ser 350 yuanes.
3.3. Aislamiento (I)
El llamado aislamiento significa que las transacciones no se afectarán entre sí y el estado intermedio de una transacción no será percibido por otras transacciones.
3.4. Durabilidad (D)
La llamada persistencia significa que después de que se completa una sola transacción, los cambios realizados en los datos por la transacción se guardan completamente en la base de datos. Esto es cierto incluso si se produce un corte de energía y el sistema no funciona.
4. Escenarios de aplicación de transacciones distribuidas
4.1. Pago
El escenario más clásico es el pago. Se realiza un pago a la cuenta del comprador y se deduce el dinero. Al agregar dinero a la cuenta del vendedor al mismo tiempo, estas operaciones deben realizarse en una sola transacción, todas tienen éxito o todas fracasan. En cuanto a la cuenta del comprador, que pertenece al centro del comprador, corresponde a la base de datos del comprador, mientras que la cuenta del vendedor pertenece al centro del vendedor, que corresponde a la base de datos del vendedor. Las operaciones en diferentes bases de datos deben introducir transacciones distribuidas.
4.2. Pedidos online
Cuando un comprador realiza un pedido en una plataforma de comercio electrónico, a menudo implica dos acciones: una es deducir el inventario y la segunda es actualizar el inventario. el estado del pedido y el inventario generalmente pertenecen a bases de datos diferentes a las de los pedidos, y es necesario utilizar transacciones distribuidas para garantizar la coherencia de los datos.
5. Soluciones comunes de transacciones distribuidas
5.1. Confirmación de dos fases basada en el protocolo XA
XA es un protocolo de transacciones distribuidas propuesto por Tuxedo. XA se divide aproximadamente en dos partes: administrador de transacciones y administrador de recursos locales.
El administrador de recursos local a menudo se implementa mediante una base de datos. Todas las bases de datos comerciales como Oracle y DB2 implementan la interfaz XA, y el administrador de transacciones actúa como programador global y es responsable del envío y la reversión de cada recurso local. El principio de XA para implementar transacciones distribuidas es el siguiente:
En general, el protocolo XA es relativamente simple y una vez que una base de datos comercial implementa el protocolo XA, el costo de usar transacciones distribuidas es relativamente bajo. Sin embargo, XA también tiene un defecto fatal, es decir, su rendimiento no es ideal, especialmente en el enlace de orden de transacción, que a menudo tiene una gran cantidad de concurrencia, y XA no puede cumplir con escenarios de alta concurrencia. Actualmente, XA se admite de manera ideal en bases de datos comerciales, pero no se admite de manera ideal en bases de datos mysql. La implementación XA de MySQL no registra los registros de la fase de preparación y el cambio entre las bases de datos primarias y secundarias genera inconsistencia de datos entre la base de datos primaria y la secundaria. . Muchos nosql tampoco son compatibles con XA, lo que hace que los escenarios de aplicación de XA sean muy limitados.
5.2. Transacción de mensajes + coherencia final
La llamada transacción de mensajes es un envío de dos etapas basado en middleware de mensajes. Es esencialmente un uso especial del middleware de mensajes. transacciones locales y envío de mensajes en una transacción distribuida para garantizar que la operación local tenga éxito y el mensaje externo se envíe correctamente, o que ambos fallen. El principio específico de RocketMQ de código abierto es el siguiente:
2. El middleware de mensajes guarda el mensaje preliminar y devuelve el éxito
3. A ejecuta una transacción local
4. A envía un mensaje de confirmación al middleware de mensajes
Una transacción de mensaje se completa mediante los 4 pasos anteriores. Para los cuatro pasos anteriores, cada paso puede causar errores, analicémoslos uno por uno:
Si hay un error en el paso uno, toda la transacción fallará y la operación local de A no será posible. ejecutado Si hay un error en el paso dos, toda la transacción fallará, la operación local de A no se ejecutará. El paso 3 cometió un error. En este momento, el mensaje de preparación debe revertirse. retroceder? La respuesta es que el sistema A implementa una interfaz de devolución de llamada para el middleware de mensajes. El middleware de mensajes ejecutará continuamente la interfaz de devolución de llamada para verificar si la transacción A se ejecuta correctamente. Si falla, se producirá un error en el paso 4 del mensaje de preparación de reversión. En ese momento, la transacción local de A es exitosa. Sí, ¿entonces el middleware de mensajes necesita revertir A? La respuesta es no, de hecho, a través de la interfaz de devolución de llamada, el middleware de mensajes puede verificar que A se haya ejecutado correctamente. En este momento, no es necesario que A envíe un mensaje de envío. completando así toda la transacción del mensaje en función del middleware del mensaje se utiliza a menudo en escenarios de alta concurrencia para dividir una transacción distribuida en una transacción de mensaje (operación local del sistema A + envío de mensajes) + operación local del sistema. B, donde la operación del sistema B está impulsada por mensajes, siempre que si la transacción del mensaje es exitosa, entonces la operación A debe ser exitosa y el mensaje debe enviarse. En este momento, B recibirá el mensaje para realizar el local. Si la operación local falla, el mensaje se volverá a entregar hasta que la operación B sea exitosa. Esto se logra encubiertamente. El principio es el siguiente:
Aunque la solución anterior puede completar las operaciones de A y B, A y B no son estrictamente consistentes, pero en última instancia sacrificamos la coherencia a cambio de una mejora sustancial del rendimiento. Por supuesto, este tipo de juego también es arriesgado. Si B continúa sin ejecutarse, la coherencia se destruirá. Depende del riesgo que pueda asumir el negocio.
5.3. Modo de programación TCC
El denominado modo de programación TCC también es una variante del envío en dos etapas. TCC proporciona un marco de programación que divide toda la lógica empresarial en tres partes: operaciones de prueba, confirmación y cancelación. Tomando como ejemplo los pedidos en línea, la etapa de prueba deducirá el inventario y la etapa de confirmación actualizará el estado del pedido. Si la actualización del pedido falla, ingresará a la etapa de cancelación y se restaurará el inventario. En resumen, TCC implementa artificialmente el envío en dos etapas a través del código. Los códigos escritos en diferentes escenarios comerciales son diferentes y la complejidad también es diferente, por lo que este modelo no se puede reutilizar bien.
6. Resumen
Las transacciones distribuidas son esencialmente un control unificado de transacciones en múltiples bases de datos. Según la fuerza del control, se pueden dividir en: sin control, control parcial y control total.
Sin control significa no introducir transacciones distribuidas. El control parcial significa el compromiso en dos fases de varias variantes, incluida la transacción de mensaje + coherencia eventual y el modo TCC mencionado anteriormente. La ventaja del control parcial es que la concurrencia y el rendimiento son muy buenos. La desventaja es que el control total sacrifica el rendimiento y garantiza la coherencia. El método a utilizar depende en última instancia del escenario empresarial. Como técnico, no debe olvidar que la tecnología sirve al negocio. No utilice la tecnología por el simple hecho de seleccionar tecnología para diferentes negocios también es una habilidad muy importante.